Codes and approvals
Use authenticator app codes, SMS codes, push approvals and QR sign-in where enabled by policy and available providers.
AIdentity / Authentication & MFA
Authentication policy decides what sign-in must prove
Multi-factor authentication (MFA) combines sign-in proofs. Choose the assurance required for the application and action. AIdentity connects sign-in methods, enrollment, recovery and step-up through policy.
Choose the right proof for the action
Phishing-resistant methods
Use supported FIDO2 and WebAuthn methods, including passkeys and security keys, for stronger sign-in.
Certificate sign-in
Human certificate and smart-card authentication is Under Development.
What this means for your team
- Configure tenant defaults and named, versioned authentication policies, with application attachment.
- Offer app TOTP, SMS OTP, push and QR authentication, FIDO2/WebAuthn, passkeys and security keys according to enabled capabilities and policy.
- Treat authenticator types honestly: an SMS code, an app code, a possession-only security key and a passkey with user verification do not prove the same thing.
- Account for factor enrollment, device removal, recovery, lockout and remembered sessions. Delivery methods need configured providers; deployment readiness is checked separately.
A practical example
A routine app accepts an allowed second factor; a privileged operation requires a stronger approved authenticator. An enrolled weaker method cannot bypass that requirement.
How it works
Select a step to read its explanation
- Identify the application and requested action, including whether the operation needs stronger authentication.
- Resolve the applicable tenant default or application policy and determine the required proof.
- Offer an enabled, enrolled method that can satisfy the policy. An available method is not automatically sufficient.
- Verify the actual authenticator evidence. A code, push response and verified passkey do not all establish identical assurance.
- Establish the permitted session, request step-up when required, or refuse the sign-in when the policy cannot be satisfied.
1 / 5
This example illustrates the journey. Select any step to explore it at your own pace.
Try an illustrative policy
Enrollment does not override the application’s policy.
This is an explanation, not the product’s policy engine. Actual assurance depends on the ceremony and evidence. SMS, TOTP, QR, push and WebAuthn do not all provide identical assurance.
Explore more AIdentity features
Who we protect
Govern people and machines without making them share an identity.
Explore this feature →RBAC, ABAC & ReBAC
Decide access using roles, attributes and relationships together.
Explore this feature →Identity lifecycle
Keep access aligned with joining, changing teams and leaving.
Explore this feature →Federation & applications
Connect applications and identity providers to a governed sign-in experience.
Explore this feature →Identity Graph
Understand who can reach a resource and which relationships give them access.
Explore this feature →Privileged roles (PIM)
Activate powerful roles for a bounded task rather than leaving them always on.
Explore this feature →Privileged access (PAM)
Govern access to privileged targets and credentials.
Explore this feature →Governance & approvals
Put reviews and independent decisions around sensitive access changes.
Explore this feature →Built-in agents & automation
Turn continuous identity analysis into evidence-backed recommendations and approved actions.
Explore this feature →Ask AIdentity
Ask questions about identity and access with authorization still enforced.
Explore this feature →Agent & device identity
Give agents and devices their own credentials, ownership and revocation path.
Explore this feature →Audit & privacy
Trace identity decisions while controlling access to sensitive evidence.
Explore this feature →