Passkey step-up
Require recent user-verified public-key authentication.
Require stronger proof when context or consequence demands it.
Combine passkeys, registered-device push challenges, number matching, device posture, and policy-driven step-up. Manually entered OTP is not described as phishing-resistant.
- Passkey step-up
- Push decisions
- Device context
What you can evaluate
Authentication strength matched to risk.
Push decisions
Bind approval or denial to a registered device and challenge.
Device context
Use evaluated posture without treating self-report as attestation.
Replay resistance
Expire challenges and refuse already-consumed proof.
Follow Multi-factor authentication from identity to evidence.
Each consequential action moves through the same six control points. See where 2AYE evaluates authority, requests human review, and preserves the outcome.
- 01IdentityWho or what is acting
- 02IntentSigned purpose and limits
- 03PolicyDeterministic evaluation
- 04ApprovalA named human when required
- 05ExecutionSingle-use grant, redeemed at the resource
- 06EvidenceReceipt joined to the audit chain
A practical adoption path
Start with one consequential workflow. Prove the boundary before expanding.
Assess
Document the environment, threat model, and integration boundary.
Design
Select protocols, signals, policies, and failure behavior.
Validate
Test vendor-specific APIs, tenant isolation, and abuse paths.
Release
Mark available only after deployed end-to-end verification.
What this includes
- Passkey step-up with recent user verification
- Registered-device push challenges with number matching
- Device posture in step-up policy
- Expiring challenges that refuse consumed proof