Official intent
Adopt multi-factor authentication that resists phishing, prioritizing privileged users and remote access. The official source remains authoritative.
Read the official campaign ↗Passwords alone are not enough. Phishing-resistant MFA — FIDO2 security keys, platform passkeys, or PIV — removes the shared secret an attacker can steal. Start with privileged and remote-access accounts, then expand to the full workforce.
Who this applies to: Every organization with cloud email, remote access, or administrative accounts. Applies to on-premises directories as well, though the enforcement mechanism differs.
Why it matters
Stolen credentials remain a common path into DIB business systems. This practice turns a phished password into a dead end instead of an account takeover.
Risks this reduces
- Account takeover using a phished, reused, or breached password
- Adversary-in-the-middle phishing that defeats push prompts and one-time codes
- Credential stuffing and password spraying against internet-facing services
- Silent persistence through legacy protocols that never see a second factor
Who owns it
Identity administrator
Executive sponsor, Help desk, MSP
Medium
Low to medium
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: IT-02 — Asset inventory
- A list of every identity provider in use, including ones an MSP administers
- Agreement on who counts as an administrator and who has remote access
- A break-glass account procedure that still works during an identity outage
Action timeline
- List accounts with admin or remote access
- Enable MFA for those accounts today
- Enroll every administrator on a phishing-resistant method and stop accepting SMS as an admin factor
- Write down and test the break-glass procedure before you tighten enforcement further
- Enroll the remote workforce
- Pilot FIDO2 keys or passkeys with one team
- Extend to the full workforce
- Block legacy protocols that bypass MFA
- Review enrollment coverage
- Test fallback and recovery paths
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Inventory identity providers and privileged accounts.
- Choose a phishing-resistant method your stack supports: FIDO2, passkeys, or PIV.
- Enforce MFA for admins and remote access first; measure coverage.
- Block legacy authentication that bypasses MFA.
- Document fallback, recovery, and break-glass procedures.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
Passwords only — or MFA is licensed and available but nobody is enrolled.
Is there anything at all — a tool, a document, a person who owns it? - Documented
A written standard names the method, the scope, and the owner. Enforcement has not been switched on.
Is the intent written down, with a named owner and a scope? - Configured
Phishing-resistant MFA is configured in the identity provider and works for a pilot group.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
Every administrator and remote-access account is enrolled and enforced. Exceptions are listed, owned, and dated.
Does it cover everything in scope, with the exceptions written down? - Measured
Enrollment coverage is reported by privilege tier, and legacy-protocol sign-ins are tracked with a target of zero.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
A named owner reviews coverage, exceptions, and recovery paths on a schedule; the review record is retained as evidence.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- Attempt sign-in with password only on a test account — it must fail.
- Review sign-in logs for legacy-protocol authentications; target zero.
- Confirm coverage by privilege tier: enrolled accounts divided by active accounts.
Evidence to retain
MFA policy with named owner and scope
Identity-policy export showing enforcement
Monthly enrollment-coverage report
Quarterly sign-in-log and recovery-path review
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Phishing-resistant coverage — privileged | Privileged accounts enrolled on a phishing-resistant method ÷ all active privileged accounts. | 100%, with every exception dated and owned. |
| Phishing-resistant coverage — workforce | All active accounts enrolled ÷ all active accounts. | Rising each month toward full coverage. |
| Legacy authentication events | Sign-ins over protocols that cannot present a second factor, counted monthly. | Zero, or an explicit allow-list with an end date. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
SMS one-time codes for administrators, MFA enabled but not enforced, and legacy protocols left open. Enrollment without enforcement is not completion.
Two sized paths
Two hardware security keys per administrator (a primary and a spare) plus platform passkeys for everyone else covers most small contractors for a few hundred dollars. Use whatever your existing cloud suite includes rather than buying a separate MFA product. Do administrators this month, the rest of the workforce next quarter, and write down the break-glass procedure before you tighten anything.
Move toward passwordless as the default sign-in, with conditional access that evaluates device compliance and sign-in risk at each authentication. Register authentication methods against an assurance level rather than a product, so a method can be deprecated without a policy rewrite. Feed enrollment and legacy-auth telemetry into the same reporting the rest of the program uses.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
Enforcement changes lock people out when they are wrong. Stage by group, keep the break-glass path outside the policy you are changing, and confirm service accounts and shared mailboxes have a documented authentication path before you block legacy protocols.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The CMMC practice inherits the 800-171 requirement text directly.
What this does not claim: Supports the requirement; it does not satisfy it on its own and does not establish an assessment outcome. Scope, implementation quality, and evidence decide that.
Why: 800-63B is where 'phishing resistance' is actually defined; it tells you which authenticator types qualify.
What this does not claim: 800-63B is a federal identity guideline, not a contractor obligation. It informs method selection; it does not impose a requirement on you.
Why: CIS separates MFA for externally-exposed applications, remote access, and administrative access — the same prioritization this practice recommends.
What this does not claim: CIS is a voluntary benchmark. Alignment with it carries no contractual weight.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.1.1Authorized access controlPartial implementation supportModerate
Why: Limiting access to authorized users is enforced at the authentication gate, and the practice hardens exactly that gate: phishing-resistant MFA enforcement plus the legacy-protocol blocking that closes the paths where weak or stolen credentials admitted unauthorized access.
What this does not claim: May partially address the requirement: 3.1.1 spans the whole account and device authorization lifecycle — whether an account should exist, whether a departed employee's access died, whether an unknown device may connect. Stronger authentication says nothing about any of that; the lifecycle and device-side work is separate and must be evaluated within the organization's defined system boundary.
Review status: Pending NIST SME review.
Open the 3.1.1 page →3.1.12Remote access monitoring and controlPartial implementation supportModerate
Why: Controlling remote access sessions begins with who can open one, and the practice puts phishing-resistant MFA on remote entry points first — its stated priority order — closing the credential-theft path that makes remote access the leading intrusion vector.
What this does not claim: Authentication strength addresses the control half for the sanctioned pathways only. The requirement's monitoring half — session logging, visibility, someone reviewing — is not produced by MFA, and unauthorized remote pathways that bypass the identity provider entirely must be found and closed by separate work.
Review status: Pending NIST SME review.
Open the 3.1.12 page →3.5.2Authentication before accessPartial implementation supportModerate
Why: Centralizing applications behind the identity provider — a step the MFA rollout forces — is how authentication-before-access becomes enforceable in one place rather than per application.
What this does not claim: The requirement covers every access path, including device authentication and paths that never join the identity provider. The practice strengthens the central path; the periphery must be evaluated separately within the organization's defined system boundary.
Review status: Pending NIST SME review.
Open the 3.5.2 page →3.5.3Multifactor authenticationDirect implementation supportHigh
Why: The practice's core activity — enforcing phishing-resistant multifactor authentication starting with privileged and remote-access accounts — works on the same population and mechanism this requirement names. The practice's method choice (FIDO2, passkeys, PIV) sits above the requirement's floor.
What this does not claim: Supports implementation of the requirement; it does not satisfy it on its own. The requirement spans every account and access path in the assessed boundary — including local privileged access and systems outside the identity provider — and an assessor evaluates scope and evidence, not intent. Phishing resistance is a method choice within the requirement, not a substitute for its coverage.
Review status: Technical review complete.
Open the 3.5.3 page →3.5.4Replay-resistant authenticationPartial implementation supportHigh
Why: FIDO2 and passkey authenticators — the methods this practice deploys — are replay-resistant by construction, so the practice advances this requirement for every access path it converts.
What this does not claim: May partially address the requirement: replay resistance must hold for all network access, including service accounts, legacy protocols, and paths the MFA rollout never touches. Those need their own analysis within the organization's defined system boundary.
Review status: Pending NIST SME review.
Open the 3.5.4 page →3.7.5Nonlocal maintenance authenticationPartial implementation supportModerate
Why: Where nonlocal maintenance sessions authenticate through the identity provider the practice governs — an administrator reaching servers over the VPN, a vendor account federated into the tenant — the practice's phishing-resistant multifactor enforcement covers the requirement's establishment clause for those paths.
What this does not claim: Covers only the paths that authenticate through the identity provider; vendor remote-support tools with their own authentication and appliance consoles reached directly bypass the enforcement entirely and are precisely where nonlocal maintenance tends to live. The requirement's second clause — terminating connections when maintenance is complete — is session lifecycle discipline the MFA rollout does not touch at all.
Review status: Pending NIST SME review.
Open the 3.7.5 page →3.13.15Session authenticityPartial implementation supportModerate
Why: The modern federated protocols the MFA rollout standardizes on — OIDC and SAML over TLS, with signed, time-limited assertions — protect the authenticity of the authentication sessions they establish, resisting hijacking and assertion replay on the paths the rollout converts.
What this does not claim: May partially address the requirement. Session authenticity spans every communications session in the boundary — TLS configuration, certificate validation, and session handling for applications, services, and infrastructure the identity rollout never touches — and post-authentication token theft remains a live attack the base protocols do not stop; token protection and session policy are separate work.
Review status: Pending NIST SME review.
Open the 3.13.15 page →NIST SP 800-171 Rev. 3
03.01.12Remote AccessPartial implementation supportModerate
Why: Phishing-resistant multifactor authentication hardens the front door of exactly the paths this requirement governs — the practice's rollout starts with remote access, and stolen credentials are how remote access is most often abused.
What this does not claim: Authentication strength is one attribute of a remote-access architecture, and not the one this requirement chiefly names. Usage restrictions per access type, authorization before connection, routing through managed access control points, and specific authorization of remote privileged work are untouched by an MFA rollout and need their own implementation. May partially address the requirement at most.
Review status: Pending NIST SME review.
Open the 03.01.12 page →03.05.01User Identification, Authentication, and Re-AuthenticationPartial implementation supportModerate
Why: Centralizing applications behind the identity provider — a step the MFA rollout forces — is what makes unique identification, authentication, and re-authentication enforceable in one place; session lifetime and sign-in frequency policy is where the re-authentication parameter gets implemented.
What this does not claim: The requirement covers every access path and adds organization-defined re-authentication circumstances the practice does not itself choose. Paths that never join the identity provider — local accounts, appliances — and the association of unique identities with running processes must be evaluated separately within the defined system boundary.
Review status: Pending NIST SME review.
Open the 03.05.01 page →03.05.03Multi-Factor AuthenticationDirect implementation supportHigh
Why: Rev. 3 restates the multifactor requirement and widens it to all access to privileged and non-privileged accounts — the same populations this practice enforces first. The practice's method choice (FIDO2, passkeys, PIV) is a stronger selection within the requirement, not an addition to it.
What this does not claim: Rev. 3 does not require phishing-resistant methods by name — choosing them exceeds the stated requirement rather than being compelled by it. The widened scope now reaches local access to non-privileged accounts, a path many MFA rollouts leave for last; the practice supports implementation but does not satisfy the requirement on its own, and an assessor evaluates coverage and evidence, not intent.
Review status: Technical review complete.
Open the 03.05.03 page →03.05.04Replay-Resistant AuthenticationPartial implementation supportHigh
Why: FIDO2 and passkey authenticators — the methods this practice deploys — are replay-resistant by construction, so every access path the rollout converts advances this requirement as a side effect of the factor choice.
What this does not claim: Rev. 3 phrases the requirement across all access to accounts, and replay resistance must hold on paths the MFA rollout never touches — service accounts, legacy protocols, appliance logins. May partially address the requirement; the untouched paths need their own analysis within the defined system boundary.
Review status: Pending NIST SME review.
Open the 03.05.04 page →03.05.12Authenticator ManagementPartial implementation supportModerate
Why: An MFA rollout runs an authenticator lifecycle whether it means to or not: verifying who is enrolling, registering keys and passkeys, replacing lost ones, revoking at departure. Done deliberately, that routine advances the issuance, protection, and revocation elements of this requirement for the factors the practice deploys.
What this does not claim: The requirement spans every authenticator type — passwords, certificates, tokens, device secrets — plus default-credential changes and organization-defined refresh, most of which sit outside an MFA deployment. May partially address the requirement for the authenticators the practice issues; the rest of the lifecycle needs its own procedures.
Review status: Pending NIST SME review.
Open the 03.05.12 page →03.07.05Nonlocal MaintenancePartial implementation supportModerate
Why: The requirement makes multi-factor authentication a condition of establishing nonlocal maintenance sessions, and the practice's phishing-resistant MFA rollout — privileged and remote access first — covers exactly those sessions wherever they authenticate through the identity provider.
What this does not claim: Authentication is one clause of three: approval and monitoring of the maintenance activity and verified termination of sessions are process obligations the MFA rollout does not create. Maintenance paths that bypass the identity provider — appliance-local logins, vendor tools with their own authentication — stay outside the practice's enforcement, and those are precisely where nonlocal maintenance tends to happen.
Review status: Pending NIST SME review.
Open the 03.07.05 page →Review status
| Technical review | Reviewed |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.0 |