Step-Up MFA: Authentication at the Moment of Risk
Always-on MFA punishes everyone for the risk of a few actions. Step-up MFA asks for more proof exactly when the risk rises. Here is how Veripass does it.
There is a tension at the heart of multi-factor authentication. Demand a second factor for everything and users learn to resent and route around it. Demand it for nothing and you have no real assurance when it matters. Step-up MFA resolves the tension by moving the question — instead of asking once at login, it asks again at the moment the risk actually appears.
Why login-time MFA is the wrong place
The standard model verifies a second factor when a user signs in and then trusts the session for everything that follows. The problem is that the riskiest action a user takes is rarely the login. It is the sensitive operation they perform twenty minutes later, on a session whose assurance was established for something far more mundane.
Login-time MFA also pays its cost in the wrong place. The friction lands on every sign-in, including the overwhelming majority that carry no particular risk, while the genuinely sensitive moment inherits whatever assurance happened to exist at login.
Step-up flips this. The everyday path stays light, and the additional proof is demanded precisely when, and only when, the risk warrants it.
How Veripass triggers step-up
Step-up is not a standalone feature in Veripass — it is an outcome of the policy engine. Access is evaluated with context: the organization, the role, the application, and the conditions of the request. When that evaluation determines the risk of an action exceeds what the current session justifies, the platform requires additional verification before allowing it to proceed.
The available factors span a range of assurance levels:
- Email one-time codes — a verification code delivered to the user’s address.
- Phone-based TOTP — a time-based one-time password from an authenticator, tied to the user’s device.
- Biometric verification — face match, ID document, or fingerprint, for the highest-assurance operations.
The session continues only once the challenge is satisfied. A routine request never sees a prompt; a high-risk one cannot proceed without one.
Risk is contextual, not a single switch
The reason step-up works is that “risk” is not a fixed property — it depends on context. The same action can be routine in one situation and sensitive in another, depending on the organization, the role, the application, and the conditions around the request.
Because Veripass evaluates that context at request time, step-up can be reserved for the situations that genuinely warrant it rather than applied as a blanket rule. That is what keeps it usable: the platform concentrates its scrutiny where the risk is, instead of taxing every interaction equally.
Step-up as a governance control
Beyond user experience, step-up is a governance instrument. It lets an organization attach a verification gate directly to its most sensitive operations, so those actions carry their own proof requirement regardless of how the session began.
And because every challenge and its outcome are written to the immutable audit trail, step-up is not only a control but also evidence. An auditor can see not just that an action occurred, but that it required additional verification and that the verification was satisfied — by a specific, federated identity.
The result is authentication placed where it belongs: not as a toll on every login, but as proof demanded at the moment of risk, recorded for accountability, and otherwise out of the user’s way.
Keep reading
Architecture Overview: Federating Identities at Scale
How Veripass federates identities across many applications and organizations from a single multi-tenant control plane, without forcing every team onto one directory.
Audit Trails That Survive an Audit
An audit trail is only useful if it holds up when someone actually audits it. Here is what makes Veripass audit records immutable, attributable, and reconstructable.
Hybrid and On-Premise Identity Without Lock-In
Not every workload belongs in the cloud. Here is how Veripass runs the same federation, policy, and audit model across cloud, on-premise, and hybrid deployments.


