Password-only authentication is no longer acceptable for organizations handling Controlled Unclassified Information (CUI); NIST SP 800-171 Rev.2 and CMMC 2.0 Level 2 (IA.L2-3.5.4) require phishing-resistant multi-factor authentication (MFA) such as FIDO2/WebAuthn or smartcard-based (PIV/CAC/EAP-TLS) access — this post gives a practical, auditable checklist and step-by-step implementation guidance for small businesses to meet that requirement.
Why phishing-resistant MFA is required and the risk of not implementing it
NIST and CMMC emphasize "phishing-resistant" because common MFA factors (SMS, OTP apps) can be intercepted or phished via real-time man-in-the-middle attacks. Without phishing-resistant MFA, attackers can steal credentials, pivot laterally, and exfiltrate CUI — leading to contract termination, regulatory fines, and reputational damage. For small businesses with limited incident response capacity, a single account compromise can be catastrophic. Implementing FIDO2 or smartcard authentication substantially reduces these risks because the private key never leaves the authenticator and authentication requires possession of a hardware-bound key plus local user presence (PIN/biometric).
High-level implementation checklist (practical, auditable steps)
Use this checklist as the backbone of your System Security Plan (SSP) and Plan of Action and Milestones (POA&M):
- Inventory: Identify all user accounts with access to CUI systems (privileged vs non-privileged, local vs remote).
- Categorize: Determine which systems can accept FIDO2/WebAuthn or smartcard/PIV login (Windows, Linux SSH, VPN, cloud SSO, web apps).
- Select solution: Choose FIDO2 hardware tokens (YubiKey, SoloKey) and/or smartcard (PIV) + PKI for certificate-based auth. For cloud identity, ensure IdP supports WebAuthn (Azure AD, Okta, Ping).
- Pilot: Run a 10–50 user pilot covering remote workers and privileged accounts; test enrollment, loss/recovery, and helpdesk workflows.
- Integrate: Configure identity provider (Azure AD Conditional Access, Okta policies) and on-prem Active Directory (Windows Hello for Business with TPM-backed keys or smartcard logon via certs).
- Enforce: Create and apply policy to block legacy/less secure auth (disable SMS/OTP-only, require hardware token for access to CUI systems).
- Recovery & lifecycle: Establish credential issuance, revocation, lost-token procedures, emergency break-glass accounts with strict controls and logging.
- Monitoring & reporting: Configure logs (Azure AD sign-in, AD event logs, RADIUS) and SIEM alerts for authentication anomalies.
- Documentation: Update SSP, POA&M, and training materials to reflect the new controls and evidentiary artifacts (policy screenshots, logs, MDM configs).
Technical integration details and configuration examples
Windows environments: Use Windows Hello for Business with certificate-backed or key-based sign-in tied to TPM for workstation logon, or deploy smartcard logon (store cert in smartcard issued by your PKI). Configure GPOs: enable "Interactive logon: Require smart card" for high-risk groups and use Conditional Access to require FIDO2 keys for Azure AD-joined devices. Example: Configure Azure AD Conditional Access policy that applies to all users accessing CUI apps and requires "Authentication Strength: Phishing-resistant MFA" and permitted FIDO2 keys.
Cloud SSO and web apps: Ensure your IdP supports WebAuthn/FIDO2 attestation and configure policies to require FIDO2 for all accounts accessing CUI scope. For Okta, enable WebAuthn as a factor and assign to specific groups; for Azure AD, register FIDO2 security keys and create Conditional Access requiring them for the CUI application resource.
Remote access (VPN/SSO): For VPNs, prefer TLS client certificate authentication (EAP-TLS with smartcards) or integrate the VPN with your IdP via SAML/OIDC where WebAuthn is enforced. For SSH, move to key-based auth using keys stored on FIDO2 tokens (OpenSSH supports FIDO/U2F keys) and disable password authentication in sshd_config (PasswordAuthentication no).
PKI and lifecycle operations
If you adopt smartcards/PIV, stand up or leverage an existing PKI: define CA hierarchy, issuance policies, certificate templates for logon/auth, CRL/OCSP availability, and automated enrollment (SCEP/ACME or Microsoft NDES/Intune). Plan lifecycle operations: certificate expiry periods, renewal automation, revocation procedures (CRL publication frequency), and offline key destruction policies for lost/stolen card scenarios. Keep an auditable ledger of issued tokens and certificates.
Real-world small business scenario
Example: A 75-person engineering subcontractor with hybrid workers and government contracts. Inventory revealed 18 accounts with CUI access. The team chose YubiKey FIDO2 tokens + Azure AD integration. Pilot with 12 users: IT configured Azure Conditional Access to require FIDO2 for CUI apps, enabled passwordless sign-in, updated the SSP to show the change, and documented enrollment screenshots and Conditional Access policy exports as evidence. They trained staff, issued tokens with PINs, set up a helpdesk process for lost tokens (temporary SSO one-time codes with manager approval and MFA verification), and disabled legacy app passwords and Basic Auth. After 6 weeks the control evidence was ready for assessment: policy documents, token issuance logs, Conditional Access policy output, and Azure AD sign-in logs showing FIDO2 successes.
Compliance tips and best practices
1) Start with privileged accounts: Prioritize privileged/local admin accounts and remote access for contractors. 2) Maintain an exceptions process documented in your SSP/POA&M with defined compensating controls and time limits. 3) Capture evidentiary artifacts: Conditional Access JSON, GPO exports, PKI CA certificates, token provisioning logs, and helpdesk tickets. 4) Avoid shortcuts like SMS/voice OTP; document why they are unacceptable. 5) Test incident scenarios: token loss, user offboarding, CA outage, and break-glass access; have emergency access procedures with multifactor sign-off and full auditing.
Implementation notes and operational considerations
Costs: hardware tokens and PKI administration incur upfront costs, but cloud solutions reduce on-prem PKI needs (Azure AD + FIDO2). Usability: pair FIDO2 with roaming vs platform authenticators depending on device mix; some users may prefer biometric platform keys (Windows Hello) while remote contractors need roaming tokens. Helpdesk: prepare scripts for enrollment, recovery, reissuance, and ensure HR offboarding triggers token revocation. Logging: ensure authentication success/failure logs include method (FIDO2 vs OTP) for audit trails. Policy alignment: map each implementation artifact to IA.L2-3.5.4 language in your SSP and keep screenshots or exported JSON/YAML as evidence for assessors.
Summary: Replacing password-only access with phishing-resistant MFA (FIDO2 or smartcard) is both a technical project and a compliance project — follow the inventory → pilot → integrate → enforce → document sequence, prioritize privileged accounts, and capture artifacts for NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 assessment. Properly implemented, phishing-resistant MFA dramatically reduces credential-based compromise risk and gives auditors clear, testable evidence that IA.L2-3.5.4 has been met.
