A common mistake is treating MFA as complete when it only covers employees or primary logins. Under NYDFS expectations, third parties and privileged accounts must be included because they are high-value paths into nonpublic information. If exceptions are allowed too broadly, attackers gain backdoors that defeat the purpose of strong authentication.
Why This Matters for Security Teams
Organisations often say MFA is “covered” when it only applies to employee sign-ins, while third parties and privileged users remain unevenly protected. That creates a false sense of completion. In practice, the highest-risk paths are usually vendor access, admin consoles, break-glass accounts, and remote support channels, where one weak exception can bypass the broader program. The risk is especially serious because privileged access is not just another user population; it is a direct path to sensitive systems and nonpublic information.
NHI Management Group research shows that 92% of organisations expose NHIs to third parties, which reinforces how often external access becomes part of the attack surface, even when MFA policy appears strong. The same pattern shows up in real incidents such as the The 52 NHI breaches Report, where weak identity coverage and overexposed access paths repeatedly become the entry point. Guidance from the OWASP Non-Human Identity Top 10 also makes clear that identity control gaps are rarely isolated. In practice, many security teams discover MFA gaps only after a vendor account or privileged session has already been used as the easiest route in.
How It Works in Practice
Effective MFA coverage starts with scoping, not technology. Security teams need to enumerate every privileged and third-party pathway that can reach nonpublic systems, including SSO apps, VPNs, PAM workflows, cloud consoles, CI/CD tools, support portals, and service desk bypasses. From there, MFA policy should be enforced for all human identities that can impact sensitive data or administrative functions, with no special treatment for vendors unless there is a documented, time-bound control alternative.
For privileged users, the practical model is usually stronger than a one-time login challenge. Best practice is to combine MFA with session controls, step-up authentication, PAM approval, and just-in-time elevation so that privilege is granted only for the task at hand. For third parties, organisations should require federated access where possible, restrict accounts to named individuals, and use conditional access rules that reflect location, device posture, and risk. The Ultimate Guide to NHIs is useful here because it ties identity sprawl, lifecycle control, and excessive privilege into one governance picture rather than treating MFA as a standalone fix.
- Verify that vendor accounts cannot authenticate through legacy paths that bypass MFA.
- Require MFA for privileged web consoles, SSH jump points, and remote administration tools.
- Document every exception with owner, expiry date, and compensating control.
- Review admin and third-party access separately from employee access reviews.
Where this guidance breaks down is in environments that still depend on shared vendor logins, long-lived break-glass accounts, or older systems that cannot support modern federation, because MFA coverage becomes inconsistent and easy to bypass.
Common Variations and Edge Cases
Tighter MFA enforcement often increases operational friction, requiring organisations to balance security coverage against vendor support speed and administrator convenience. That tradeoff is real, but current guidance suggests the exception process is where risk accumulates fastest. A narrowly scoped exception for one third-party tool can become a permanent backdoor if it is never revisited.
There is no universal standard for every edge case, but a few patterns come up repeatedly. Shared accounts are the weakest option because MFA becomes tied to a credential rather than a person. Service-provider access sometimes needs federated identity, device trust, or PAM-mediated access instead of direct authentication into production systems. Privileged users may also require stronger controls than ordinary MFA, such as phishing-resistant methods and session reauthentication for sensitive actions. This is consistent with the control intent in OWASP Non-Human Identity Top 10 and with incident patterns highlighted in the 52 NHI Breaches Analysis.
The key question is not whether MFA exists, but whether it actually protects the people and paths most likely to be abused. If privileged and third-party exceptions are too broad, the program looks compliant while leaving the most valuable access routes exposed.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Access control scope must include third parties and privileged users. |
| NIST SP 800-63 | AAL2 | MFA strength and assurance level matter for high-risk authenticated access. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification, not assumed trust for vendors or admins. | |
| OWASP Non-Human Identity Top 10 | NHI-04 | Over-privileged and exposed identities are often the bypass path behind weak MFA coverage. |
| CSA MAESTRO | MAESTRO addresses identity and access controls for autonomous and delegated workloads. |
Extend access policies to every privileged and third-party path, then verify enforcement continuously.
Related resources from NHI Mgmt Group
- What do organisations get wrong about privileged access for third parties?
- What do organisations get wrong about third-party privileged access?
- What do organisations get wrong about protecting personal data inside ERP systems?
- What do organisations get wrong about retaining personal data collected through websites and community portals?
