ASVS V6.3.3 requires that access to the application uses either a multi factor mechanism or a combination of single factor mechanisms. At Level 3, one of the factors must be hardware based and resistant to phishing, and it must require a user action such as pressing a button on a FIDO key. Relaxing any part needs a documented rationale and mitigating controls. The baseline is Level 2, with the hardware requirement at Level 3.
Why it matters
A password alone is the factor attackers steal most often. A second factor stops credential stuffing and most phishing of the password. Phishing resistant factors such as passkeys and security keys also stop real time proxy phishing, where a code is relayed to the real site.
The two levels differ. At Level 2 you need either true MFA or a combination of single factor mechanisms. At Level 3 the bar rises: one factor must be hardware based, resistant to phishing and tied to a user action. The reason is that ordinary one time codes can be relayed. An attacker who runs a fake login page forwards the password and the code to the real site within the validity window, and gets in.
How to implement it
Offer WebAuthn as the strongest option, with TOTP as a fallback for Level 2. Verify the assertion on the server.
// Server: verify a WebAuthn assertion (using @simplewebauthn/server)
const v = await verifyAuthenticationResponse({
response: body,
expectedChallenge: session.challenge,
expectedOrigin: "https://app.example.com",
expectedRPID: "app.example.com",
authenticator: storedCredential,
requireUserVerification: true,
});
if (!v.verified) return res.sendStatus(401);
Bind the challenge to the session, check origin and RP ID, and require user presence. Enforce the factor on every pathway, not just the main login. Provide secure recovery that does not downgrade to email only.
Pick the strongest option you can support, then build fallbacks that do not undermine it.
For registration, let the user enrol at least two methods, for example a passkey and a recovery code set. For sign in, ask for the password and the second factor, or accept a passkey that already includes user verification.
For step up, ask for a fresh factor before sensitive actions such as changing the email or payment details.
For recovery, avoid weakening to a single email click. Use stored backup codes, a second authenticator, or a supported identity proofing process with a delay and notices.
For policy, decide which roles must use hardware keys. Administrators and users with access to sensitive data are the obvious first group.
Record your decisions. The requirement says any relaxation needs a documented rationale and mitigating controls, so write the risk, the compensating measure and an owner and review date.
How to test it
Sign in with a password only on every entry point, including the API and SSO. Access must be denied until the second factor passes. For Level 3, attempt a login on a lookalike domain and confirm the hardware credential does not release.
Create a matrix of users and pathways and confirm the enforced factors in each cell. Try these specific cases: sign in through the API with a password only; sign in via SSO with an IdP session that never saw MFA; complete a reset and see whether MFA is still required; disable MFA from a session that has not recently authenticated.
For Level 3, test a phishing proxy in a lab. Point a lookalike domain at a relay and confirm that the passkey or FIDO assertion fails because the origin differs. Also confirm that a user presence or verification step is required, so a key left plugged into an unlocked machine cannot be used silently.
Common mistakes
-
SMS as the only second factor at higher levels.
-
MFA on the web login but not the mobile API.
-
A recovery flow that skips the second factor.
-
Letting users disable MFA with just a password.
-
Treating push approvals with no number matching as strong. Users approve prompts they did not start.
-
Allowing the user to choose SMS during a downgrade.
-
Counting a device cookie as a factor when it is really remembered state.
-
Failing to enrol a spare key, which leads to account lockouts and weak recovery.
Quick check
Why does Level 3 want hardware keys?
They are bound to the real origin, so a phishing site cannot reuse the response.
