Step-up authentication
Who this is for
Security teams, tenant admins, and developers who need to understand how Owlie protects sensitive actions inside an authenticated session.
Goal
Understand when Owlie requests additional proof, which methods can satisfy it, and why MFA enrollment behaves differently from later MFA changes.
Prereqs
- Understand your tenant's MFA enforcement and enabled methods.
- Know that roles and permissions determine which actions a user may perform.
Success criteria
- You can distinguish authorization from step-up authentication.
- You can predict whether Owlie will request primary or second-factor verification.
- You can explain why first MFA enrollment normally does not show another prompt after sign-in.
Mental model
Step-up authentication asks a signed-in user to prove their identity again before Owlie completes a sensitive action. It does not grant permission or add access.
Owlie evaluates a protected action in this order:
- Confirm that the user is authorized to perform the action.
- Check when the session last completed the required type of authentication.
- If that proof is missing or too old, request an available verification method.
- After successful inline verification, retry the original action once.
A user without the required permission receives a normal access denial. Completing step-up cannot turn that denial into access.
Assurance levels
Owlie tracks primary and second-factor authentication separately.
| Level | What satisfies it |
|---|---|
| Recent primary authentication | The user's primary sign-in, a password verification in the dashboard, or a new sign-in through the tenant's existing magic-link or SSO method. |
| Recent second-factor authentication | A current authenticator-app code or an enrolled passkey. |
Passkeys are second factors only in Owlie. They never establish or refresh primary authentication. MFA backup codes cannot satisfy a step-up prompt.
How Owlie chooses the requirement
The protected action and the factors already enrolled on the user's account determine the requirement. The dashboard being used and the user's admin or operator role do not select a weaker or stronger authentication level. Roles still determine whether the action is authorized.
| Protected action | Required recent proof |
|---|---|
| Change your password or regenerate administrator emergency-recovery codes | Primary authentication within 10 minutes. |
| Enroll your first authenticator app or passkey | Primary authentication within 30 minutes. |
| Add another authenticator or passkey after any usable second factor exists | Second-factor authentication within 5 minutes. |
| Remove an authenticator or passkey | Second-factor authentication within 5 minutes when a usable factor exists; otherwise primary authentication within 10 minutes. |
| Regenerate MFA backup codes | Second-factor authentication within 5 minutes. |
| Change another identity's password | The required admin permission and second-factor authentication within 5 minutes. |
| Change tenant-wide MFA requirements | The required settings permission, plus primary authentication within 10 minutes when no usable factor exists or second-factor authentication within 5 minutes when one does. |
The first-enrollment rule avoids asking a user to verify with a factor they have not created yet. Once any usable factor exists, Owlie raises the requirement for enrollment and destructive MFA changes to that factor.
These freshness windows are fixed by the protected operation. Tenant MFA settings control which methods users may enroll and when MFA is required during sign-in; they do not change the step-up windows.
What users see
When more proof is needed, Owlie names the pending action, for example Before adding a passkey, confirm it’s you, and offers methods valid for that requirement.
- A primary prompt can offer password verification.
- A second-factor prompt can offer an authenticator code, a passkey, or both.
- If an SSO or magic-link account needs fresh primary authentication, Continue to sign in sends the user through their configured sign-in and returns them to the same location. The user then repeats the protected action.
Owlie does not show a prompt when the session already carries sufficiently recent proof.
Example
Maya signs in with SSO at 9:00 and enrolls her first passkey at 9:20. Her primary sign-in is inside the 30-minute first-enrollment window, so Owlie does not interrupt her with another prompt.
At 9:25, Maya adds an authenticator app. Because a passkey now exists, Owlie asks her to verify with that passkey before starting the new enrollment. If she later removes a factor after the five-minute second-factor window has expired, Owlie asks for another authenticator-code or passkey verification.
The result is the same in the end-user and admin dashboards.
Impact and risks
- A stolen but still-valid session alone cannot silently perform protected changes after the relevant freshness window expires.
- A first-factor enrollment relies on recent primary authentication because no second factor exists yet.
- Once a usable, policy-enabled second factor exists, a password alone cannot satisfy step-up for adding, replacing, or removing an MFA method.
- Step-up protects the action only after normal authorization succeeds; it is not a substitute for least-privilege roles and permissions.
Troubleshooting
A passkey is not offered for a primary prompt
This is expected. Owlie uses passkeys only as second factors. Verify with a password, or select Continue to sign in when that option appears.
Owlie requests a second factor while the user is enrolling MFA
The account already has a usable authenticator or passkey. Verify with an enrolled factor before adding another one.
The user returns from SSO but the action did not complete
Returning through sign-in refreshes the session and returns the user to the same location. Repeat the protected action there.
Verification succeeds but access is still denied
Check the user's role and permissions. Step-up proves identity freshness; it does not grant authorization.
No valid verification method is available
For removal of a factor made inactive by tenant policy, a recent primary sign-in can satisfy the check. For a second-factor-only action, ask a tenant admin to review the enabled MFA methods, then enroll an allowed authenticator or passkey before retrying.
Limitations
- Step-up applies to browser-session actions. API keys and impersonated sessions cannot perform the protected credential and MFA changes described here.
- Freshness windows are not tenant-configurable.
- Owlie does not use passkeys as primary login credentials.