Security teams should require multi-factor authentication wherever passwords alone would expose corporate resources to phishing, reuse, or credential theft. The decision should be based on risk context, device trust, location, user sensitivity, and application value. Adaptive policies let teams raise assurance for unusual logins while keeping routine access workable for users and avoiding blanket disruption across every sign-in.
How to set MFA policy without making every login equally hard
The practical question is not whether MFA is useful, it is where the assurance gap is large enough that password-only access is an unacceptable control. Teams should treat MFA as a baseline for any path that can reach sensitive systems, privileged functions, or high-value data, then vary the enforcement strength by access context rather than by preference or convenience.
That means the policy should distinguish low-risk routine access from logins that are unusual, externally exposed, or likely to be targeted. A finance workflow, admin console, developer platform, or remote access path deserves a stricter default than a low-impact internal app, especially when the underlying credential is reusable, long-lived, or likely to be phished.
The decision also needs to account for the asset being protected, not just the user. Corporate access to email, SSO, source code, ticketing, production infrastructure, and admin tools can all become pivot points for broader compromise, so MFA should follow the path that would materially expand blast radius if it were stolen.
Risk signals that should raise the MFA requirement
Risk rises when the sign-in context suggests phishing, replay, token theft, or credential stuffing is more likely to succeed. That includes access from unmanaged devices, unfamiliar geographies, impossible travel patterns, first-time locations, high-velocity login bursts, and applications that are attractive because they expose sensitive data or act as a launch point for other systems.
Adaptive MFA is most useful when teams can identify those signals early and route them into stronger assurance before access is granted. For example, a normal office login to a low-risk app may remain simple, while the same account requesting access to privileged tooling or a new device posture should trigger step-up verification.
Policy should also reflect user sensitivity. Executives, finance operators, help desk staff, security administrators, and developers with production access often present a larger compromise impact than a typical knowledge worker because their accounts can reach systems, approvals, or secrets that unlock more of the environment.
It is also worth remembering that password-only access fails quickly once credentials are reused or phished. Real-world breach reporting shows how stolen credentials and over-permissive access paths turn a single login into wider compromise, which is why security teams should use MFA as a control against account takeover, not as a checkbox on a login screen. NHIMG’s Microsoft Midnight Blizzard breach and Uber Breach both illustrate how weak or bypassed authentication can become an entry point for much broader access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | MFA policy is tied to credential theft and reuse risk for access paths. |
| NHI-03 — Authentication and Session Management | Step-up authentication and session assurance are central to deciding when MFA should trigger. | |
| NHI-05 — Authorization and Privilege Boundaries | MFA thresholds should follow the sensitivity of the resource and the privilege being exercised. | |
| Recommendation — Require MFA on access paths where stolen credentials could unlock sensitive systems or privileged functions. Apply step-up MFA when session risk, device trust, or location makes the login unusually sensitive. Align MFA enforcement with privilege level and the impact of the requested access path. | ||
| CIS Controls v8 | 6.3 — Data Recovery, Account Monitoring, and Audit Trail Review | Account monitoring and audit signals inform when login risk justifies stronger MFA. |
| 6.4 — Access Control Management | Access control decisions should reflect business need and sensitivity, which drives MFA scope. | |
| 6.7 — Authentication and Access Control | This control directly addresses enforcing stronger authentication where access risk is elevated. | |
| Recommendation — Use account and access telemetry to trigger MFA on anomalous or high-risk sign-ins. Set MFA requirements by access sensitivity, business need, and trust context. Enforce stronger authentication for sensitive systems and step up assurance for risky logins. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The question is fundamentally about when authentication controls should be applied. |
| PR.AA-05 — Access Permissions and Authorizations | Authorization context helps determine which resources justify stronger authentication. | |
| PR.PT — Protective Technology | MFA is a protective technology used to reduce compromise risk from passwords alone. | |
| Recommendation — Map MFA requirements to identity assurance and access control decisions for each access path. Tie MFA enforcement to the permissions and authorizations behind the resource. Deploy MFA as a protective layer on access paths with material compromise potential. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Assurance level selection depends on the risk of the access transaction and the resource. |
| Recommendation — Select MFA strength to match the assurance required for the transaction. | ||
Practitioner Guidance
What to prioritise: Put MFA first on any access path that can reach sensitive business data, admin consoles, production systems, or reusable credentials with broad reach. If the account can open a higher-trust session or a privileged tool, the threshold for step-up authentication should be low.
Decision rule: If the login context is outside normal device, network, or user behaviour, require stronger MFA immediately rather than waiting for confirmed abuse. If the access is routine, low impact, and tightly constrained, keep the workflow usable but still protected by the baseline control.
What to verify: Check that the policy is tied to actual blast radius, not job title alone. The best indicator is whether a successful sign-in would let the user read sensitive data, approve payments, change configuration, or reach another control plane.
Common mistake: Treating MFA as uniform because it is easy to administer. Blanket enforcement without context can push users into workarounds, while blanket exceptions quietly preserve the exact weak paths attackers look for.
Practitioner takeaway: The right MFA policy is risk-based and path-based, not universal for its own sake, the goal is to force extra proof only when the sign-in could reasonably lead to meaningful compromise.
Related resources from NHI Mgmt Group
- How should security teams implement multi-factor authentication for sensitive access without creating user workarounds?
- How should security teams choose between 2-factor authentication, multi-factor authentication, and adaptive MFA for remote and hybrid access?
- How should security teams decide between FGA and ABAC for modern access control programs?
- How should security teams run access reviews for non-human identities?
