Subscribe to the Non-Human & AI Identity Journal
Home FAQ Governance, Ownership & Risk Who needs to be included in MFA and…
Governance, Ownership & Risk

Who needs to be included in MFA and access assurance planning for CMMC?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated June 12, 2026 Domain: Governance, Ownership & Risk

Employees, subcontractors, and privileged users all need to be considered because CMMC assesses the full access boundary, not just the internal workforce. If any of those groups can reach systems without the required assurance level, the programme has a certification gap rather than a minor policy exception.

Why This Matters for Security Teams

CMMC access assurance planning is not limited to employees on the payroll. It has to account for everyone who can reach CUI systems or influence control outcomes, including subcontractors, administrators, and any privileged operators with elevated reach. The practical risk is that MFA coverage can look complete on paper while gaps remain in the real access boundary, especially where third-party access, shared admin paths, or exception handling are involved.

That matters because assurance failures are usually systemic, not isolated. If a subcontractor, support engineer, or privileged user can authenticate through a weaker path, the control objective is already diluted. NHI Mgmt Group notes that 92% of organisations expose NHIs to third parties, which is a useful reminder that access assurance problems often extend beyond direct employees and into supplier-managed workflows in the same environment as Ultimate Guide to NHIs. For identity proofing and authentication strength, current guidance aligns more closely with NIST SP 800-63 Digital Identity Guidelines than with informal internal policy.

In practice, many security teams encounter MFA gaps only after a supplier account, shared admin credential, or exception workflow has already been used during assessment, rather than through intentional pre-certification review.

How It Works in Practice

Effective CMMC planning starts with the full access boundary, then maps every person and service account that can touch covered assets. That means employees, subcontractors, contractors, privileged users, and any third-party support path need to be inventoried together. The question is not whether they are on the org chart, but whether they can authenticate, re-authenticate, escalate, or bypass MFA in a way that affects CUI protection.

Practitioners usually separate planning into four steps:

  • Identify all identities with direct or indirect access to in-scope systems, including vendor and subcontractor accounts.
  • Classify which accounts require MFA, which require stronger access assurance, and which need privileged access management instead of standard login controls.
  • Verify that service desks, break-glass paths, and delegated administration cannot silently bypass the required assurance level.
  • Document how access is provisioned, reviewed, and removed so the control can survive assessment, not just internal audit.

This is where NHI governance and human access planning overlap. If a third party uses API keys, service accounts, or automation to support CMMC-scoped systems, those identities should be treated as part of the assurance boundary, not as a separate technical footnote. The broader risk picture in the 52 NHI Breaches Analysis shows why: access gaps are often operational, not theoretical, and they are frequently exposed through weak lifecycle controls rather than a single bad login.

For MFA itself, the control should be tested against every path into the environment, including federated access, remote support, privileged workflows, and any exception that depends on manual approval. These controls tend to break down when subcontractors rely on inherited credentials or shared admin channels because the assurance level cannot be proven consistently at the point of access.

Common Variations and Edge Cases

Tighter assurance controls often increase operational overhead, so organisations have to balance stronger verification against vendor friction, help desk burden, and assessment readiness. That tradeoff is especially visible when subcontractors need time-bound access, when privileged users need emergency access, or when a supplier cannot support the same MFA method as internal staff.

Best practice is evolving for these edge cases, but the current direction is clear: do not weaken the requirement, redesign the access path. If a partner cannot meet the required assurance level, the solution is usually conditional access, delegated management, or a different onboarding model, not an exception that quietly persists past the assessment window. The same logic applies when service accounts are used to bridge human workflow. If those accounts can reach protected systems, they should be governed with the same seriousness as human identities, even if the implementation is different.

There is no universal standard for every exception pattern, but assessors generally expect organisations to show that MFA coverage and access assurance were considered for all reachable identities, not only full-time employees. That includes temporary staff, outsourced admin teams, and anyone with privileged reach into CUI-bearing systems. Current guidance from OWASP Non-Human Identity Top 10 reinforces the broader point that identity assurance fails when organisations ignore non-standard access paths, even if the immediate question is framed around people rather than NHIs.

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 NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST SP 800-63AALMFA planning depends on assurance level across all user types and access paths.
NIST CSF 2.0PR.AA-1Access assurance requires identifying and authenticating all authorised users.
OWASP Non-Human Identity Top 10NHI-01Third-party and service identities often create hidden access assurance gaps.

Treat non-human and delegated identities as part of the same access boundary and govern them explicitly.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on June 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org