Fragmented identity infrastructure creates risk because access policies, assurance levels, and workflows become harder to govern consistently across missions and environments. That inconsistency increases the chance of privilege creep, delayed reviews, and weak enforcement of Zero Trust controls. When teams cannot centralise identity decisions, compliance work becomes slower and operational risk rises across defence networks and partner ecosystems.
How fragmentation breaks Zero Trust execution
zero trust depends on consistent identity decisions at the point of access. When identity services, directories, policy engines, approval workflows, and logging are split across commands, clouds, and partner environments, the control plane stops behaving like one system. The result is not just inconvenience, it is inconsistent assurance, uneven enforcement, and gaps between the policy intent and the access that actually gets granted.
Fragmentation also weakens operational clarity. Teams spend more time reconciling who owns the identity record, which authority approved it, and whether the same assurance level is enforced everywhere. That slows access reviews, complicates exception handling, and makes it harder to prove that access decisions are being made from a common source of truth.
For Zero Trust programmes, the practical issue is that compliance is judged on repeatability as much as on policy language. If one environment uses strong authentication and another still relies on legacy exceptions, the organisation may have policies on paper but not a dependable enforcement pattern in practice.
Why fragmented identity increases governance and mission risk
Identity fragmentation creates conditions for privilege creep because entitlements tend to accumulate in separate systems with different review cadences. It also increases the chance that orphaned accounts, stale credentials, or inconsistent role definitions survive longer than intended, especially when missions move quickly and administrators apply local fixes to keep operations running.
That risk is amplified in defence settings because mission partners, contractors, and cross-domain workflows often need tightly scoped access across multiple systems. If identity governance is not unified, the organisation can end up with access that is technically available but not demonstrably controlled, which undermines both audit readiness and trust in the Zero Trust model itself.
Fragmentation also raises the odds of hidden exposure in non-human access paths. NHI Management Group research shows that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, and only 5.7% of organisations have full visibility into their service accounts. That gap matters because identity sprawl is not only a control problem, it is a monitoring problem.
What good looks like in a DoD Zero Trust environment
The strongest posture is a federated identity design with central policy intent, shared assurance rules, and local execution only where it is explicitly allowed. That means the organisation can answer the same questions consistently across domains: who the actor is, what level of trust is required, what access is permitted, and how quickly that access is removed when the mission ends.
Practitioners should treat consistency as the test of readiness. If access requests, recertification, and revocation follow different rules in different enclaves, the identity layer is still fragmented even if the tools are modern. The objective is not a single product, it is a single governance model that survives operational variation.
For a broader Zero Trust reference point, NIST SP 800-207 Zero Trust Architecture remains the clearest external anchor for policy enforcement, least privilege, and continuous verification. For infrastructure identity specifically, SPIFFE workload identity specification is useful when the problem extends into service-to-service trust and workload attestation.
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 CSF 2.0, NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication and Access Control | Fragmented identity directly affects how access is governed and enforced across environments. |
| Recommendation — Standardise identity governance and access enforcement across environments to keep access decisions consistent. | ||
| NIST Zero Trust (SP 800-207) | AC-1 — Policy Enforcement Point and Continuous Verification | Zero Trust depends on consistent policy enforcement and continuous verification across trust zones. |
| Recommendation — Centralise policy decisions and enforce them consistently at each access point. | ||
| CIS Controls v8 | 6 — Access Control Management | Fragmentation increases entitlement drift, review delays, and weak revocation discipline. |
| Recommendation — Consolidate account and access reviews so privileges are granted and removed on a repeatable schedule. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Identity fragmentation often leaves credentials and access paths unmanaged across systems. |
| NHI-03 — Overprivilege and Access Creep | Separate identity systems make privilege creep harder to detect and correct. | |
| NHI-09 — Visibility and Lifecycle Management | DoD Zero Trust compliance depends on knowing which identities exist and who owns them. | |
| Recommendation — Inventory and rotate credentials centrally so fragmented environments do not accumulate hidden access paths. Use least privilege reviews to remove accumulated access that no longer matches mission need. Maintain a complete identity inventory and lifecycle process across all environments. | ||
| NIST SP 800-63 | AAL — Authenticator Assurance Levels | Fragmentation can create uneven assurance levels across systems and missions. |
| IAL — Identity Assurance Levels | Identity proofing drift across domains weakens confidence in who is being granted access. | |
| Recommendation — Align authentication strength to the required assurance level everywhere an identity is used. Apply a common proofing standard so identity assurance remains comparable across the enterprise. | ||
Practitioner Guidance
What to verify: Check whether access reviews, assurance levels, and revocation rules are identical across major mission environments, or whether each enclave is quietly operating its own exceptions. If the answer changes by platform, the organisation does not yet have a stable Zero Trust identity model.
What to measure: Track how long it takes to revoke access after mission completion, how many identities have multiple ownership paths, and how many review exceptions are carried forward from one cycle to the next. Rising exception counts are usually a stronger warning sign than a single policy gap.
Decision rule: If the same identity can receive different trust outcomes depending on where it authenticates, prioritise harmonising policy, ownership, and logging before adding more controls. Fragmented enforcement is difficult to audit and even harder to fix after it becomes embedded in operations.
Practitioner takeaway: Zero Trust compliance fails fastest when identity governance is local but access risk is enterprise-wide, so the real control objective is to make identity decisions repeatable, attributable, and removable across every environment.
Related resources from NHI Mgmt Group
- How should security teams implement risk-based identity governance in a Zero Trust model without relying on periodic access reviews alone?
- Why does combining identity risk signals with access governance improve Zero Trust decisions for critical access?
- Why do non-human identities create compliance risk even when policies exist?
- Why does partial Zero Trust create compliance risk?