Step-Up Authentication vs 2FA: Implementing Additional Verification for Sensitive Operations in Corporate Systems
Two-factor authentication (2FA) has become a standard for protecting corporate systems, yet it often proves insufficient for handling personal data or other high-risk operations. While 2FA verifies identity only at login and then grants access for the duration of the trusted session, modern attacks increasingly target already-active sessions. This limitation prompted the adoption of Step-Up Authentication, which requests additional confirmation precisely when a user attempts a sensitive action.
Why Standard 2FA Falls Short
Common second factors include SMS or Email OTP, TOTP from authenticator apps such as Yandex Key, Google Authenticator, Microsoft Authenticator, or Authy, and other one-time codes. These methods protect the login process effectively but do not re-verify identity during an ongoing session. As a result, prolonged sessions or shared devices can expose critical resources without further checks.
What Step-Up Authentication Provides
Step-Up Authentication differs by triggering extra verification only at the point of elevated-risk operations. Typical scenarios include work on shared devices, long-lived sessions, or access requests that demand a higher trust level than the initial login provided. In the described project, this mechanism was applied specifically when users attempted to retrieve salary information, requiring re-authentication only for selected APIs.
The technical foundation relies on ACR (Authentication Context Class Reference) values embedded in tokens. These values indicate whether login occurred with password alone or with an additional OTP. Applications inspect the ACR claim and either grant access or redirect the user for further authentication.
Project Implementation Challenges and Solution
Although Keycloak and WSO2 both support Step-Up Authentication out of the box, the project’s business requirements exceeded standard capabilities. The PIN code had to remain valid for six months, external systems needed to treat it as a user password, and verification had to occur at a separate gateway layer independent of the Identity Provider. These constraints made heavy customization of WSO2 impractical.
The team therefore created an independent PIN-code service and a dedicated gateway-2fa microservice. Only requests to protected APIs pass through this gateway; all other traffic follows the normal route. The flow works as follows:
- The web application directs the user to the PIN service to generate a code.
- The service creates an encrypted PIN, stores it, and delivers it via email and SMS.
- After successful entry, the service issues a signed cookie with a defined TTL confirming Step-Up completion.
- On subsequent protected calls, gateway-2fa validates the cookie and cross-checks key JWT fields; mismatches result in denial of access.
User Experience and Monitoring
From the user’s perspective, the additional step appears only when accessing protected data. A 401 response prompts PIN entry; successful validation sets the cookie, after which the user can work with sensitive resources until the TTL expires (set to 20 minutes in this implementation). Incorrect PIN attempts simply keep the resource inaccessible.
Usage statistics are collected in Matomo and technical metrics in ELK, enabling early detection of performance issues or unusual patterns.
Key Considerations for Deployment
Successful rollout requires careful definition of TTL duration, strong encryption for stored PINs, load testing of the additional service, and logging that supports incident investigation without exposing sensitive user data. The resulting architecture strengthens protection for critical operations while preserving a seamless login experience and supporting Zero Trust principles.
Related articles
Positive Technologies Adds Unified Console to PT X for Centralized Incident and Asset Management
Positive Technologies has introduced a single console within its PT X platform that combines incident management, asset control, and security posture assessment. Customers can now monitor attack attempts around the clock, view possible causes, track response status, and prioritize events without switching between multiple interfaces. The system lets organizations predefine which assets Positive Technologies may act upon and choose between manual customer response, automatic PT X actions, or approval-based workflows, with full audit reports generated afterward. A dedicated dashboard highlights coverage gaps by showing hosts protected by MaxPatrol EDR and flagging assets without agents installed. Machine learning capabilities have been expanded through a combination of large language models and classical ML to accelerate early attack detection and automate handling of low- and medium-severity incidents. Additional features include external perimeter analysis that reveals internet-facing resources from an attacker’s perspective and a bug-bounty-style cyber testing program that rewards researchers for identifying unacceptable events.
Meta Allows Over 50 Paid Ads Sexualizing Minors to Run on Facebook, Instagram, Messenger and Threads
Meta's advertising moderation systems failed to detect and remove more than 50 paid advertisements containing sexualized images of minors across its major platforms. The ads, some generated using generative AI tools, appeared on Facebook, Instagram, Messenger, and Threads over a nine-month period. Researchers at Tech Transparency Project identified that several of these advertisements remained active into early August. The content was not organic user posts but commercially purchased ads that bypassed Meta's review processes. The incident highlights ongoing weaknesses in automated and human moderation of paid promotional material involving prohibited themes. Tech Transparency Project emphasized that the scale and persistence of the ads point to systemic gaps in Meta's enforcement mechanisms for child safety policies.
Yandex Go Develops Custom DSL to Handle Complex Dynamic Ride Pricing Logic
Yandex Go has moved its ride pricing algorithm out of the main service code into a dedicated domain-specific language to avoid frequent deployments and tangled conditional logic. The pricing system accounts for geozones, demand surges, discounts, toll roads, extra stops, and special requirements such as transporting pets or sports equipment. Parameters are collected in parallel, dependencies are modeled as a graph, and requests run asynchronously on userver so that a single slow source does not break the entire calculation. Because rules change on average twice a week, keeping the logic in C++ would require rebuilding and redeploying 50 pods for roughly 40 minutes each time. The new DSL supports conditions, functions, immutable values, and fold operations instead of loops; rules are chained so each step receives the current price and metadata and returns an updated result. ANTLR 4 defines the grammar while the Z3 verifier ensures programs cannot produce invalid prices. The platform is already used by Yandex Taxi, Delivery, and the electric-vehicle charging service.
Third Edition of The Ultimate Kali Linux Book Released with Expanded OSINT and Pentesting Coverage
The publishing house Piter has released the third international edition of The Ultimate Kali Linux Book by Glen Singh. The updated volume provides comprehensive guidance on using Nmap, Metasploit, Aircrack-ng and Empire for ethical hacking and penetration testing. Significant revisions include a new chapter on OSINT, refreshed practical exercises and clearer descriptions of virtual lab environments. The book targets both beginners and experienced IT professionals seeking to master vulnerability assessment, wireless network testing and web application exploitation. Readers learn to build testing labs, perform reconnaissance, exploit network weaknesses and evaluate corporate infrastructure security. Author Glen Singh holds an MSc and multiple certifications from EC-Council, Cisco and Check Point, bringing real-world Red Team and Blue Team experience to the material.