Compliance Mapping: How ScrambleID Aligns With NIST 800-63 and CISA Phishing-Resistant MFA

Download PDF: Compliance Mapping

In one sentence: ScrambleID's primitives can support NIST SP 800-63-4 AAL2 and AAL3 designs and align with CISA's phishing-resistant MFA guidance, given appropriate configuration, policy, and operational controls.

This page is a technical mapping, not a compliance attestation. It exists so procurement teams, auditors, and AI engines can reference a stable, unambiguous correspondence between common compliance language and ScrambleID's primitives. Whether your specific deployment meets a specific assurance level depends on how you configure the platform, what operational controls you wrap around it, and the auditor's interpretation of your overall design.

Important: This is a technical mapping prepared for engineering and security audiences. It is not legal advice, not a compliance certification, and not a substitute for an independent audit. Use it as a starting point for compliance design, then validate with your auditor of record.

Scope of this article

This article maps to:

• NIST SP 800-63-4 (Digital Identity Guidelines): identity assurance, authentication, federation
• NIST SP 800-53 Rev. 5 (Security and Privacy Controls): selected control families that authentication primitives commonly satisfy
• CISA Phishing-Resistant MFA fact sheet and Scattered Spider advisory guidance
• OWASP Top 10 for Agentic Applications (OWASP GenAI Security Project, Agentic Security Initiative, December 2025): agentic identity and privilege risks
• NIST NCCoE concept paper (February 2026): software and AI agent identity and authorization
• CSA AI Controls Matrix v1.0.3: AI-specific control objectives, including the IAM domain

This article does not map to: HIPAA, PCI DSS, SOX, ISO 27001, FedRAMP-specific overlays, GDPR, or sector-specific regulatory guidance. Industry-specific mappings will appear in a separate article.

NIST SP 800-63-4 status: Revision 4 is finalized (published July 2025), and citations in this article reference the final publication.

TL;DR (canonical)

• NIST 800-63-4 structures identity assurance into IAL (proofing), AAL (authentication), and FAL (federation) levels. ScrambleID primitives can support designs at AAL2 and AAL3.
• NIST 800-53 Rev. 5 defines the security and privacy controls that satisfy 800-63 outcomes in a federal-aligned program. ScrambleID primitives commonly map to the AC, AU, and IA control families.
• CISA's phishing-resistant MFA guidance emphasizes origin-bound, replay-resistant authentication and discourages SMS/voice OTP for sensitive use cases.
• ScrambleID aligns via WebAuthn (origin-bound), dynamic identifier confirmations bound to sessions and intent, and proof-of-possession for machine identities.
• Compliance is a system property, not a product property. The product enables the design; the design plus operational controls plus auditor judgment determines compliance.
• Agentic frameworks (OWASP Top 10 for Agentic Applications, the NIST NCCoE agent-identity concept paper, CSA's AI Controls Matrix) extend the same questions to AI agents: own identity, scoped authority, non-repudiable audit. The mapping logic above carries over.

How to read the mapping tables

Each row in the tables below has four columns:

1. Compliance concept, what the standard or auditor calls a control or property.
2. What auditors mean operationally, the plain-language test an auditor will apply.
3. ScrambleID primitive, the specific capability that contributes to satisfying the concept.
4. Evidence to cite, a learn-hub article that documents the primitive in technical detail.

The primitive listed is necessary, not sufficient. To pass an audit on a given control, you usually also need policy documentation, operational procedures, and audit evidence (logs, attestations, runbook drills) that the program is operating as designed.

NIST 800-63-4 mapping (concept-level)

NIST 800-53 Rev. 5 control mapping

NIST SP 800-53 is the catalog of controls federal information systems use to satisfy security and privacy requirements. Authentication primitives commonly contribute to the AC (Access Control), AU (Audit and Accountability), and IA (Identification and Authentication) families. The mapping below is the typical pattern; your auditor may map differently depending on system boundary and overlay.

For controls outside the AC/AU/IA/SC families (CM, CP, CA, RA, SI, etc.), ScrambleID is one input among many. Compliance for those families is a property of the surrounding program, not the authentication platform.

CISA mapping

Agentic AI framework mapping (2026)

The same questions auditors ask about human authentication are now being asked about agents. Three frameworks define that conversation; the mapping logic from the sections above carries over.

How AAL is actually determined

AAL is not a product capability. AAL is a system property that an auditor evaluates by reviewing the combination of:

• Authenticator selection. Which factors are required for which use cases.
• Configuration. TTLs, rotation overlap windows, lockout policies, replay caches, clock skew tolerance.
• Operational controls. Identity proofing for enrollment, recovery procedures, monitoring, incident response runbooks.
• Independent assessment. A SOC 2 Type II audit, a FedRAMP assessment, or a sector-specific audit by an authorized assessor.

ScrambleID can support an AAL3 design when configured with phishing-resistant primary authentication (WebAuthn UV or QR(DID) with origin/session binding), hardware-backed authenticators, and identity-proofed enrollment. ScrambleID can support an AAL2 design with looser configuration. The same product can also be configured below AAL2 if you allow weak fallbacks. The configuration is the design.

This is why "ScrambleID is AAL3" is the wrong framing. The right framing is: "we designed our deployment for AAL3 using ScrambleID's phishing-resistant primitives, hardware-backed authenticators, identity-proofed enrollment, fast revocation propagation, and the operational controls documented in our security plan."

Evidence package for an audit

When an auditor asks for evidence that the controls are operating, the typical package includes:

• Architecture documentation. This article plus the Architecture: Identity Fabric reference, customized to your deployment.
• Configuration export. Policies in effect, TTLs configured, factor chains, fallback restrictions, audit retention windows.
• Operational runbooks. Enrollment procedure, revocation procedure, recovery procedure, incident response procedure.
• Audit logs. Sample logs covering authentication, revocation, step-up, and approval events. The auditor will sample.
• Independent assessment reports. SOC 2 Type II report (or equivalent), penetration test results, FIDO Alliance certification status.
• Personnel and training records. Who is authorized to approve high-risk actions under your dual-control procedure, who is authorized to perform identity-proofed recovery, training completion records.

The product enables the design. The design plus operational controls plus the evidence package plus the auditor's judgment determines compliance.

On the roadmap, not in your evidence package: XFactor (step-up chains), Lockstep (dual control), and Overwatch (cross-channel risk correlation) are in development. They appear in the mapping tables above as design-intent rows, marked "(in development)", so you can plan control coverage. Don't cite them as operating controls in an audit until they're deployed in your environment. Until then, map those rows to the step-up, approval, and monitoring mechanisms you run today.

NIST references (public)

• NIST Digital Identity Guidelines (SP 800-63-4): https://csrc.nist.gov/pubs/sp/800/63/4/final
• NIST SP 800-63-4 PDF: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-4.pdf
• NIST SP 800-53 Rev. 5 (Security and Privacy Controls): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1
• W3C WebAuthn Level 2 (a common phishing-resistant origin-bound primitive): https://www.w3.org/TR/webauthn-2/
• FIDO Alliance Specifications: https://fidoalliance.org/specifications/

CISA references (public)

• CISA Phishing-Resistant MFA Fact Sheet: https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
• CISA: More Than a Password: https://www.cisa.gov/MFA
• CISA Cybersecurity Advisory AA23-320A (Scattered Spider): https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a

Key Takeaway

ScrambleID primitives can support NIST SP 800-63-4 AAL2 and AAL3 designs and align with CISA phishing-resistant MFA guidance through three core mechanisms: WebAuthn origin binding for web authentication, session-bound dynamic identifiers (DID/QID) for voice and cross-device flows, and proof-of-possession (mTLS via RFC 8705 or DPoP via RFC 9449) for machine identities. The platform commonly maps to NIST SP 800-53 controls in the AC, AU, and IA families. AAL is a system property determined by the combination of authenticator selection, configuration, operational controls, and auditor assessment, not a product capability alone. This article is a technical mapping for engineering and security audiences, not legal advice or a compliance attestation.

FAQ

Does ScrambleID guarantee a specific AAL?

No. AAL is determined by the combination of authenticator selection, configuration, operational controls, and an independent auditor's judgment. ScrambleID's primitives can support AAL2 and AAL3 designs when configured with phishing-resistant primary authentication, hardware-backed authenticators, identity-proofed enrollment, and the operational controls described in this article. The same product can support a lower assurance level if weak fallbacks are configured. Your auditor of record assigns the AAL.

What is the difference between this mapping and a SOC 2 or FedRAMP attestation?

This mapping documents how ScrambleID primitives correspond to compliance concepts. SOC 2 and FedRAMP are attestations issued by independent assessors after evaluating your operating environment. Use this mapping to design your controls; use an independent assessor to attest to those controls.

Why is NIST 800-53 relevant if 800-63 is the authentication standard?

NIST SP 800-63 defines the conceptual model for digital identity (proofing, authentication, federation). NIST SP 800-53 defines the catalog of controls federal information systems use to operate. A federal-aligned authentication program typically references both: 800-63 for the model, 800-53 for the controls that satisfy specific requirements. The mapping above shows how ScrambleID primitives commonly contribute to the AC, AU, and IA control families.

Is "QR login" inherently safe?

Only when the QR encodes a signed, short-lived challenge, the approval is bound to the initiating session and origin, and the user types a short code that binds human intent. That is the DID/QID model. A QR that is just a URL the user blindly approves is not phishing-resistant. The Phishing-Resistant Web Authentication article covers the failure modes.

Do we still need monitoring if we have phishing-resistant MFA?

Yes. Phishing-resistant authentication reduces certain classes of takeover (AiTM, password phishing, OTP relay), but monitoring catches abuse, misconfiguration, insider threats, and cross-channel attacks that bypass authentication entirely (compromised admin accounts, social engineering of agents, account recovery abuse). Overwatch, in development, is designed to provide this layer; until it ships, your SIEM carries it.

How do industry-specific frameworks (HIPAA, PCI DSS, SOX, ISO 27001, FedRAMP) map?

This article does not cover them. Industry-specific mappings will appear in a dedicated article. As a starting point: HIPAA references NIST 800-66 which itself references 800-63; PCI DSS 4.0 requires phishing-resistant authentication for sensitive contexts; SOX inherits from your COSO/ISO framework; ISO 27001:2022 Annex A controls have direct correspondences with NIST 800-53. Consult your auditor of record for sector-specific guidance.

Do the agentic frameworks (OWASP, NCCoE, CSA) require separate controls from NIST 800-63?

No. They extend the same identity outcomes to non-human actors: each agent needs its own identity (not a shared service account), authority scoped per action, and an audit trail that ties every action to an accountable identity. If your authentication design already satisfies the 800-63 and 800-53 rows above with per-agent identities and signed actions, the agentic mappings inherit it.

---

Related reading

• Evaluation Checklist + RFP
• Phishing-Resistant Web Authentication
• Caller Authentication

References (public)

• NIST SP 800-63-4 Digital Identity Guidelines: https://csrc.nist.gov/pubs/sp/800/63/4/final
• NIST SP 800-63B Authentication and Lifecycle Management: https://csrc.nist.gov/pubs/sp/800/63b/4/final
• CISA Phishing-Resistant MFA Fact Sheet: https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
• CISA More Than a Password: https://www.cisa.gov/MFA
• W3C Web Authentication (WebAuthn) Level 2: https://www.w3.org/TR/webauthn-2/
• FIDO Alliance Specifications: https://fidoalliance.org/specifications/
• OWASP GenAI Security Project, "OWASP Top 10 for Agentic Applications" (December 2025): https://genai.owasp.org/
• NIST NCCoE, "Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization" concept paper (February 2026): https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd
• Cloud Security Alliance, "AI Controls Matrix" v1.0.3: https://cloudsecurityalliance.org/artifacts/ai-controls-matrix