Verifier binding
Authentication output cannot be reused at an impostor origin.
Use cryptographic proof bound to the legitimate verifier.
Passkeys provide verifier-bound public-key authentication. OTP and manually entered codes remain supported factors but are not represented as phishing-resistant.
- Verifier binding
- User verification
- Recovery controls
What you can evaluate
End-to-end phishing-resistant access.
User verification
Require local activation or biometric verification as policy demands.
Recovery controls
Do not let weaker recovery silently bypass the stronger factor.
Coverage review
Identify every privileged and remote-access entry point.
Follow Phishing resistance 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
- Verifier-bound passkey authentication
- User verification required as policy demands