Defence Industrial Base Identity Security Guide: CMMC, Cyber Essentials and Supplier Access

Defence suppliers are targeted for their identities as much as their designs: one contractor account with weak authentication can expose controlled data from a whole programme and the primes it supplies. The defence industrial base (DIB) spans primes, small machine shops, software houses, engineering consultancies and managed service providers, and most of them now face contractual identity requirements: CMMC and DFARS clauses in the United States, the Defence Cyber Protection Partnership Cyber Security Model (DEFSTAN 05-138) and Cyber Essentials in the UK. This guide focuses on the identity side of those regimes: scoping the accounts and identity systems that touch Federal Contract Information (FCI) and Controlled Unclassified Information (CUI), authentication and privileged access, supplier and subcontractor access, and the non-human identities that often sit outside the assessment. It is written for security, IT and compliance leads at defence suppliers of any size. It does not repeat the control-by-control walk-through in the NIST SP 800-171 and CMMC 2.0 Guide, and it is not legal advice.

Key takeaways

• Identity systems are in scope. Under 32 CFR 170.19 the identity provider, MFA service and privileged access tooling that protect CUI systems are Security Protection Assets and are assessed against the Level 2 requirements relevant to their function.
• CMMC is now a contract condition. DFARS 252.204-7021 (November 2025) requires a current CMMC status for every system handling FCI or CUI, an annual affirmation in SPRS and flowdown to subcontractors before award.
• Some identity gaps cannot be deferred. Level 1 allows no POA&M at all, and Level 2 POA&Ms are limited to one-point requirements and must close within 180 days, so authentication weaknesses need fixing before assessment, not after.
• Supplier access is the soft edge. External service providers, cloud services and subcontractor accounts are either inside your assessment scope or must carry their own assurance (FedRAMP Moderate or equivalent for cloud), and attackers use trusted relationships (ATT&CK T1199) to reach primes.
• The UK route runs through the Cyber Security Model. MOD contracts use DEFCON 658 and DEFSTAN 05-138, now at Cyber Security Model version 4, with Cyber Essentials setting the identity floor: MFA on every cloud service and separate administrator accounts.

Why defence suppliers are an identity problem

The threat model for a defence supplier is different from a typical commercial firm in three ways. First, the data is valuable to state actors, who are patient and favour valid credentials over noisy exploits. Second, the supplier is often small, running Microsoft 365 or Google Workspace with a part-time IT provider, while handling technical drawings or test data for a much larger programme. Third, access crosses organisational boundaries all the time: primes host collaboration portals, subcontractors log in to shared engineering systems, and managed service providers hold standing administrative access to dozens of small DIB customers at once.

• Valid accounts (T1078) and cloud accounts (T1078.004): password spraying (T1110.003) against cloud email and collaboration tenants remains the cheapest way into a small supplier.
• Phishing (T1566) and MFA request flooding (T1621): push-based MFA without number matching is routinely defeated. See the AiTM Phishing Guide and the MFA Fatigue and Bypass Guide.
• External remote services (T1133): VPN and remote access gateways that terminate on a single password, or whose session tokens can be stolen. The CitrixBleed 2023 breach, which reached Boeing among others, showed that stolen session tokens bypass MFA entirely when sessions are not revoked after patching.
• Trusted relationship (T1199) and supply chain compromise (T1195): an MSP or subcontractor account with standing access is a path into every customer it serves.
• Insider and fake identity risk: fraudulent remote hires and over-privileged staff are an identity proofing and lifecycle problem. See the Insider Threat from Fake IT Workers Guide.

The regulatory picture for identity

The table summarises the regimes most DIB suppliers meet and what they mean for identity. Dates and status are as stated in the primary sources listed at the end; check the current text of your contract, because the applicable clause and level are set per solicitation.

Phasing: 32 CFR 170.3 starts Phase 1 on the effective date of the 48 CFR acquisition rule (10 November 2025) and adds a phase each year, reaching full implementation in Phase 4. In practice this means CMMC requirements appear in a growing share of solicitations through 2028, so suppliers that wait for a specific contract leave themselves little time. The CUI Guide covers how to recognise CUI, and the Cyber Essentials Guide covers the UK scheme in full.

Scoping identity: what the assessor will look at

Scope drives cost and effort. Under 32 CFR 170.19, Level 2 assets fall into five categories, and identity infrastructure lands in the most demanding ones more often than organisations expect.

• Enclave or whole estate: a separate CUI enclave (for example a dedicated government cloud tenant or VDI environment) shrinks scope but needs its own identity boundary. If the enclave trusts the corporate identity provider, that provider is a Security Protection Asset and the enclave's protection is only as strong as it is.
• Federation and trusts: Active Directory forest trusts and SAML or OIDC federation into the enclave extend scope. Document every trust and why it is needed. See the Federation and Trust Relationships Guide.
• Specialized Assets: shop-floor machines often use shared operator logins. CMMC accepts this only as a documented, risk-managed exception; compensate with physical access control and network segmentation. See the Device and IoT Identity Guide.

Authentication and privileged access

Most failed or delayed assessments trace back to a small set of identity requirements. In NIST SP 800-171 Rev. 2 (the CMMC Level 2 baseline) these are numbered 3.5.x and 3.1.x; Rev. 3 renumbers them as 03.05.03 Multi-Factor Authentication, 03.01.05 Least Privilege, 03.01.12 Remote Access and so on. Map to whichever revision your contract names, and design to Rev. 3 where you can so the next transition is smaller.

• MFA everywhere it is required: MFA for privileged accounts and for network access by non-privileged accounts. Prefer phishing-resistant methods (FIDO2 security keys, platform passkeys, PIV/CAC or certificate-based smart cards) for administrators and remote access first. See the Phishing-Resistant MFA Guide and the Smart Card and PIV/CAC Authentication Guide.
• Close legacy paths: block legacy authentication protocols (IMAP, POP, SMTP AUTH, basic authentication) in the cloud tenant; otherwise MFA can be bypassed with a password alone.
• FIPS-validated cryptography: CUI encryption (3.13.11) must use FIPS-validated modules. It is the one requirement above one point that may go on a POA&M, and only where encryption is used but not validated. Authenticators, VPNs and remote access gateways should use validated modules from the start.
• Separate privileged accounts: administrators use dedicated accounts with no mailbox or web browsing, which is also a Cyber Essentials requirement. Use just-in-time elevation where the platform supports it. See the Privileged Access Management Guide.
• Session controls: session lock after inactivity, session termination, and revocation of tokens after password resets or suspected compromise.
• Break-glass accounts: keep two emergency accounts, excluded from conditional access only where unavoidable, with long random credentials held offline and alerting on every sign-in. See the Break-Glass Account Guide.
• The reporting credential: DFARS 7012 incident reports need a DoD-approved medium assurance certificate. Obtain it before an incident, assign it to named people, and include its renewal in your credential inventory.

Cyber Essentials floor (UK): the v3.2 requirements say MFA must always be used for cloud services, and password-based accounts need either a 12-character minimum, an 8-character minimum with a common-password deny list, or MFA, plus throttling (no more than 10 guesses in 5 minutes) or lockout after no more than 10 failed attempts. A supplier meeting CMMC Level 2 authentication controls will usually meet these, but check cloud services that sit outside the CUI scope, because Cyber Essentials covers the whole organisation unless a subset is defined.

Supplier, subcontractor and service provider access

Identity crosses the supply chain in both directions: your staff use primes' portals, and your subcontractors and providers use yours. Each relationship needs a decision on whose identity is used, whose controls apply and who can revoke access.

• Flowdown is an identity task: DFARS 252.204-7021 requires the prime to confirm a subcontractor's CMMC status before award and to ensure annual affirmations. Keep a register of which suppliers hold which status and UID, and which of their people hold accounts in your systems. See the Third-Party Access Guide and the Contractor Identity Lifecycle Guide.
• Foreign persons and export-controlled data: ITAR and EAR technical data often sits in the same systems as CUI. Access control lists must reflect nationality-based authorisations, and providing login credentials to a foreign person can itself be a release under ITAR (22 CFR 120.56). Involve your export compliance officer when designing groups and attributes.
• UK suppliers to US programmes and vice versa: ISN 2021/03 addresses compliance with cyber requirements from other nations, and a UK subcontractor on a US contract can receive CMMC flowdown. Map once to both regimes rather than running two programmes.

Non-human identities in the defence supply chain

Assessments focus on users, but the accounts that move CUI are often machines: service accounts on PLM systems, API tokens for file transfer, CI/CD credentials in software suppliers and scripts that sync engineering data with a prime. NIST SP 800-171 identification and authentication requirements cover processes acting on behalf of users and devices, so these are in scope.

• Inventory: list every service account, API key, certificate and token that can reach CUI systems, with an owner. Start from the Service Account Inventory Template.
• Remove interactive use: service accounts should not be able to log on interactively; use managed service accounts where available. See the Service Account Security Guide.
• Vault and rotate: move secrets out of scripts and configuration files into a vault with rotation and access logging. The Poland ArcGIS password leak, where a login emailed years earlier exposed military mapping data, shows how long an unrotated credential stays useful. See the Secrets Management Guide.
• Certificates: FIPS-validated TLS and device certificates need lifecycle management; an expired certificate on a CUI file transfer often leads to a rushed, insecure workaround.

Implementation roadmap

1. Confirm obligations: read the DFARS clauses and CMMC level in current and expected contracts (and DEFCON 658 risk profile for MOD work). Record which systems hold FCI, CUI or export-controlled data.
2. Draw the identity boundary: list identity providers, directories, MFA services, PAM tools, MSP tooling and trusts, and classify each under 32 CFR 170.19. Decide enclave versus whole estate.
3. Fix the non-deferrable items first: anything that cannot go on a POA&M (all Level 1 requirements, Level 2 requirements above one point, the SSP itself). MFA, account management and least privilege belong here.
4. Pilot authentication changes: deploy phishing-resistant MFA to administrators and remote access first, then to all CUI users in rings. Run conditional access policies in report-only mode for one to two weeks, review sign-in logs for blocked legitimate traffic, then enforce. Keep break-glass accounts tested so you can roll back a bad policy.
5. Bring suppliers in: inventory third-party and MSP accounts, convert shared logins to named accounts, add end dates and sponsors, and collect CMMC status and UIDs for subcontractors.
6. Vault non-human credentials: rotate service account passwords and API keys reachable from CUI systems; remove hard-coded secrets.
7. Evidence and self-assess: collect configuration exports, access reviews and logs; score against the assessment objectives; enter results in SPRS; prepare the affirming official.
8. Operate: quarterly access reviews, annual affirmation, and change control for any new trust or supplier connection.

Small versus large suppliers: a 20-person machine shop usually does best with a single cloud tenant in a government cloud region or a managed CUI enclave, where the provider's responsibility matrix covers much of the work, and a small number of security keys for everyone. A large prime typically runs an enclave strategy per programme, a central PAM service and a supplier portal with its own federation, and has to manage hundreds of subcontractor flowdowns. The decision point for both is whether CUI is concentrated (choose an enclave) or spread across engineering workflows (raise the whole estate, at higher cost).

Detection and measurement

Log sign-ins, MFA events, privileged role activations, account creation and group changes in the identity provider, and forward them to a SIEM that is itself a Security Protection Asset. Alert on impossible travel, sign-ins from unexpected countries for export-controlled groups, MFA request bursts, new OAuth consents, new federation trusts and break-glass use. Preserve logs and images long enough to meet the DFARS 7012 90-day preservation duty after an incident.

• MFA coverage: percentage of accounts with access to CUI enrolled in phishing-resistant MFA (target 100% of administrators).
• Legacy authentication: number of successful sign-ins using legacy protocols in the last 30 days (target zero).
• Third-party hygiene: percentage of supplier and MSP accounts with a named sponsor and end date.
• Leaver speed: median time from contract or employment end to account disablement, including external portals.
• Machine credentials: percentage of service accounts and API keys in a vault with rotation.
• Flowdown status: percentage of active subcontractors handling FCI or CUI with a confirmed current CMMC status.

Framework mapping

Relevant ATT&CK techniques for threat-informed testing: T1078, T1078.004, T1110.003, T1566, T1621, T1133, T1199 and T1195. See the MITRE ATT&CK Guide for Defenders.

Common failure patterns

• Leaving the identity provider out of scope: an enclave that federates to an unassessed corporate directory, so an assessor finds the real control point was never documented.
• MFA with holes: MFA enforced in the portal but legacy authentication still allowed, or VPN sessions not revoked after a gateway vulnerability. The CitrixBleed 2023 breach is the clearest illustration.
• MSP super-accounts: one shared administrator account used by every technician across many customers, with no logging visible to the supplier.
• Treating subcontractor flowdown as paperwork: status collected at award but supplier accounts never reviewed or removed when work ends.
• Ignoring machine credentials: service account passwords unchanged for years and API keys in scripts on engineering workstations.
• Planning to POA&M everything: discovering at assessment that higher-weighted identity requirements cannot be deferred and the 180-day window is too short.

Practitioner checklist

• Record the CMMC level, DFARS clauses or DEFCON 658 risk profile for every current and expected contract.
• Classify every identity system and trust under the 32 CFR 170.19 asset categories and document it in the SSP.
• Enforce phishing-resistant MFA for administrators and remote access, then all CUI users; block legacy authentication.
• Give administrators separate accounts and use just-in-time elevation; test two break-glass accounts.
• Document every External Service Provider and cloud service in the SSP and responsibility matrix, and confirm FedRAMP Moderate or equivalent for cloud holding CUI.
• Keep a supplier register with CMMC status, UID and named accounts; review supplier access quarterly.
• Inventory, vault and rotate service accounts, API keys and certificates reaching CUI systems.
• Obtain the DoD-approved medium assurance certificate for incident reporting before you need it.
• Align ITAR and EAR access groups with export authorisations and involve export compliance in group design.
• Track the six metrics above and present them with the annual affirmation.

Standards and references

• eCFR: 32 CFR Part 170, Cybersecurity Maturity Model Certification (CMMC) Program
• eCFR: DFARS 252.204-7021 Contractor Compliance with the CMMC Level Requirements
• eCFR: DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting
• NIST: SP 800-171 Rev. 3, Protecting Controlled Unclassified Information
• UK Ministry of Defence: Industry Security Notices (ISNs)
• NCSC: Cyber Essentials Requirements for IT Infrastructure v3.2
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Trusted Relationship

Related NHI Mgmt Group resources: NIST SP 800-171 and CMMC 2.0 Guide · CUI Guide · Third-Party Risk Management Guide · Ransomware Prevention Guide · EDR Evasion and Defence Guide. This guide summarises CMMC, DFARS, DEFSTAN 05-138 and Cyber Essentials identity requirements and is not legal advice.