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
How a Personal Site Counts Bots Without Storing Any IPs: Pure PHP, No Database, Strict CSP and 160 Tests
A personal website built entirely in pure PHP without frameworks or databases demonstrates advanced defensive security practices while tracking bot activity from an SSH honeypot. The site stores all content in a single JSON file with atomic writes and automatic backups, eliminating database-related attack surfaces and simplifying deployment to folder copying. Strict Content-Security-Policy rules prohibit inline styles and scripts without nonces, forcing the use of SVG attributes, CSSOM updates, and JSON data blocks instead of direct attribute injection. Over 160 automated tests written in PHP attack the site with XSS payloads, CSRF attempts, path traversals, and malformed Markdown to verify that no malicious output reaches the browser. Bot identification relies on behavioral signatures derived from the first twelve cleaned commands of each session, combined with HASSH fingerprints and activity patterns, allowing the site to report unique bot families and address counts without ever publishing IPs. Additional browser-based tests using Chromium validate accessibility, performance budgets, and CSP compliance across desktop and mobile viewports. The entire system runs with zero external dependencies and integrates tests directly into the deployment pipeline.
Russian Finance Ministry Seeks Central Bank Reports on Systematic P2P Transfers to Tax Authorities
The Russian Ministry of Finance has proposed amendments requiring the Central Bank to share data with the Federal Tax Service on individuals whose bank accounts show signs of regular income received from other private citizens. The changes target article 85 of the Tax Code and form part of the budget package bill numbered 617-9. Under the new rules, the Central Bank would identify such citizens through transaction analysis and transmit the information according to a future agreement with the tax service. The Federal Tax Service would also gain expanded powers to request bank statements from non-entrepreneurs without needing prior debt collection or audit triggers. If approved, the provisions would take effect on 1 January 2027 and apply to operations conducted after 1 January 2026. Separate bills under discussion would impose monthly transfer limits of 30,000 rubles on suspected clients starting in 2028 and require the tax service to notify the Central Bank about account openings and income categories.
Baidu Launches Ciyuan Exchange to Establish Trust Standards for AI Model Trading
Baidu Intelligent Cloud has introduced the Ciyuan Exchange, a dedicated trading platform for large AI models that aims to solve quality verification and credit issues in an increasingly crowded market. The platform, unveiled at the Baidu World 2026 Conference, already hosts over 100 supply resources with daily calls exceeding 50 million and daily token usage surpassing 700 billion. Founder Li Yanhong positioned the exchange as an infrastructure layer that moves beyond simple model aggregation toward verifiable identity, ongoing performance monitoring, and supplier credit records. The initiative addresses real procurement risks where identical models from different providers show up to twofold differences in throughput and reliability, according to a China Academy of Information and Communications Technology report. By combining model fingerprinting, capability testing, periodic audits, and continuous credit scoring, the platform seeks to create transparent market mechanisms similar to commodity exchanges. This development signals a broader industry shift from raw model capability competition toward standardized service quality, pricing transparency, and reliable delivery infrastructure.
Windows and MacBook Pro Setup Combines Local Network Access with Dual VPNs and Kill Switch Protection
A user detailed how they integrated an older MacBook Pro into an existing Windows workstation environment while preserving separate user accounts, file sharing, and independent VPN connections. The setup required careful routing configuration to keep the Kill Switch active on both Amnezia VLESS and AmneziaWG without breaking local SMB connectivity. After initial failures caused by the Windows Kill Switch blocking the 192.168.1.0/24 subnet, split tunneling was implemented to route local traffic directly. Separate macOS accounts were created for daily use and a dedicated “Serverok” account for remote scripting and compute tasks. SSH and SFTP ultimately replaced problematic SMB shares for the secondary account, enabling reliable file transfers at over 50 MB/s. The configuration allows simultaneous or sequential use of both machines while maintaining strong VPN protection on each.