Control objective
Multi-factor authentication requires evidence from at least two distinct factor types in one authentication result. Factor types include something the claimant knows, possesses, or is. Two passwords are not two factors. A password and a code delivered to the same compromised device can also share important failure modes.
Ceremony and independence
The verifier must validate each required factor or a multi-factor authenticator that is activated with a second factor. Bind all evidence to the same authentication transaction and relying party. Evaluate whether one compromise, recovery process, or social-engineering path can defeat all factors.
Attack resistance
MFA reduces many password-only attacks, but method choice matters. A phisher can relay passwords and one-time codes. Push approval can suffer fatigue attacks. Subscriber-chosen recovery can bypass the strong method. Public-key credentials bound to the legitimate relying-party domain can provide phishing resistance.
Failure and residual risk
MFA does not stop session theft after authentication. It does not prove that a device is healthy or that the account has narrow permissions. Enrollment and replacement can become the weakest path. Factors can also become unavailable, so recovery must not silently lower assurance.
Pomerium boundary
The configured identity provider performs the MFA ceremony and tells Pomerium the authentication result through federation. Operators must configure and verify the provider's methods and policies. Pomerium then applies its route authorization to the resulting session.
Evaluation checklist
- Do the required authenticators represent distinct factor types and failure paths?
- Can an attacker relay or socially engineer the ceremony?
- Does enrollment and recovery preserve the intended assurance?
- Is fresh authentication required for sensitive actions?
- What protects the authenticated session after MFA succeeds?
