Framework overlap

Does Azure Security Benchmark cover FIDO2 / WebAuthn?

You hold Azure Security Benchmark and have been told to do FIDO2 / WebAuthn. Here is how much overlaps, control by control.

13% of FIDO2 / WebAuthn you already have

Azure Security Benchmark already covers about 13% of FIDO2 / WebAuthn, leaving 14 of 16 controls as genuinely new work.

Already covered 2 Likely covered 0 New work 14

What is genuinely new work

Nothing in Azure Security Benchmark reaches these. This is the list to scope.

FIDO2-Attestation
Attestation Statement Formats and Verification
FIDO2-Authentication-Ceremony
WebAuthn Authentication Ceremony (Credential Assertion)
FIDO2-CTAP2-PIN-UV
CTAP2 PIN, User Verification (UV) and PIN/UV Auth Tokens
FIDO2-CTAP2-Transport
CTAP2 Transports (USB-HID, NFC, BLE, Hybrid / caBLE, Platform-internal)
FIDO2-CTAP2.1-API
FIDO CTAP2.1 Authenticator API Commands and Credential Management
FIDO2-Enterprise-Attestation
Enterprise Attestation and AAGUID Allowlisting
FIDO2-FIDO-Certification
FIDO Alliance Certification Programs - Authenticator + Server + Biometric Component
FIDO2-MetadataService-MDS
FIDO Metadata Service v3 (MDS3) - AAGUID Trust + Status Reports
FIDO2-RP-Identity
Relying Party Identifier, Origin Binding, Cross-Origin and Conditional UI
FIDO2-Registration-Ceremony
WebAuthn Registration Ceremony (Credential Creation)
FIDO2-Status
FIDO2/WebAuthn Implementation Status, Passkey Adoption and 2024-2025 Trends
FIDO2-UserVerification
User Verification (UV) - PIN, Biometrics and Multi-Factor Inside Authenticator
FIDO2-WebAuthn-API-L3
W3C WebAuthn Level 3 API (PublicKeyCredential + navigator.credentials)
FIDO2-WebAuthn-CredentialOptions
PublicKeyCredentialCreationOptions + RequestOptions (registration + authentication parameters)
Show the 2 you already have
FIDO2-Passkey-Discoverable
Passkeys (Discoverable Credentials) and Account Recovery
FIDO2-Phishing-Resistance
Phishing Resistance, Channel Binding, Anti-Replay and Privacy

How this is calculated

Already covered means a mapping runs from a control in Azure Security Benchmark to that control. Likely covered means no direct mapping exists but both frameworks map to the same control in a third standard. New work means neither. We keep those separate rather than adding them into one friendlier number, because blending them would present a two-hop inference as a verified fact.

Coverage is not symmetric. Run it the other way and you will get a different number; both are correct.

From 332,959 cross-framework control mappings across 723 frameworks, 531 of them verified against their source documents. It does not tell you that you are compliant: a mapped control means the two standards ask for the same thing, not that you have done it.

Try another pair ยท Today's edition