Defence organisations should anchor the migration on a unified identity control plane that standardises access decisions, enforces policy consistently, and supports both legacy and modern user populations. The goal is to reduce infrastructure sprawl without weakening assurance. That approach helps teams protect mission-critical data, simplify compliance, and keep access aligned to Zero Trust requirements across hybrid and multi-cloud environments.
Why shared-cloud identity has to be treated as the control plane, not just an access layer
For IL4 and IL5 workloads, the identity layer is where shared-cloud deployments either stay governable or become fragmented. The key design choice is to centralise policy decision points while still preserving workload-specific boundaries, so one environment can support different mission profiles without creating separate access models for every team, platform, or cloud account.
A practical structure separates authentication, authorisation, and audit. Authentication should be consistent across user populations and workload populations; authorisation should be policy-driven and workload-aware; audit should show who or what received access, under which conditions, and for which mission system. That keeps the control plane unified while letting the workloads remain isolated where it matters.
Shared cloud also raises the bar for consistent role design. If access rules differ by tenancy, cloud service, or legacy platform, organisations usually end up with duplicated accounts, inconsistent privilege boundaries, and difficult recertification. A better pattern is to standardise the identity model first, then map legacy and modern access paths into it with explicit control exceptions rather than implicit one-off grants.
For cloud identity design, the most useful reference points are the CSA Cloud Controls Matrix for cloud governance structure and CIS Controls v8 for account, access, and logging discipline. Where the shared environment depends on federated sign-in and strong assurance, NIST SP 800-63 Digital Identity Guidelines helps shape assurance decisions at the user boundary.
How to keep IL4 and IL5 workloads separable without rebuilding identity twice
The main engineering challenge is not simply granting access, it is making sure the same identity fabric can enforce different sensitivity levels cleanly. IL4 and IL5 workloads often share platform services, operational tooling, and administrators, but they should not share uncontrolled standing privilege or broad trust assumptions. Separation should be expressed in policy, scope, and administrative boundaries, not just in naming conventions.
That means using explicit environment segmentation, tightly scoped roles, and strong entitlement review for every path that crosses workload boundaries. In practice, mission systems should inherit only the minimum identity attributes and permissions needed to function, and the cloud platform should enforce those permissions consistently whether access comes through console, API, automation, or support tooling.
For organisations moving from siloed hosting to shared cloud, the most robust pattern is to treat legacy and modern access as different entry points into the same control model. Legacy directories, federated identity, privileged administration, and workload credentials can coexist, but they should all terminate in a single policy vocabulary so the security team can reason about privilege drift, access exceptions, and revocation in one place.
When workload trust depends on service-to-service authentication, SPIFFE workload identity specification is a strong model for ephemeral, verifiable workload identity, while NHIMG’s Ultimate Guide to NHIs provides the governance lens for lifecycle, visibility, and privilege control. Those two views fit well together in shared cloud because they address both runtime trust and operational ownership.
What breaks first when identity is not standardised in shared defence cloud
The first failure is usually privilege sprawl. When each programme, cloud account, or platform team defines access differently, organisations accumulate excessive permissions, stale access paths, and poorly understood dependencies between human users, service accounts, and automation. The second failure is control ambiguity: no one can quickly answer which identity is authorised for which mission function, or whether the access is still justified.
That ambiguity becomes operationally expensive during incident response and accreditation. If revocation depends on manual tracing across multiple identity stores, you lose the ability to act quickly when a credential, token, or administrative account is exposed. A shared cloud platform is only defensible when revocation, review, and logging are as centralised as provisioning.
For mission environments, the practical risk is not just compromise, it is loss of confidence in the boundary itself. If the identity model cannot distinguish IL4 from IL5 access conditions at the policy layer, the organisation will either over-restrict users and slow delivery or over-permit them and create exposure. The right answer is disciplined federation, explicit exceptions, and continuous review of the identities that can cross the boundary.
Practitioner Guidance: Start by inventorying every identity path that can reach an IL4 or IL5 workload, then classify each path as human, privileged, automated, or workload-to-workload. That classification should drive a single policy model, because the common mistake is to design for the directory first and discover too late that the real risk sits in service accounts, API access, and administrative tooling.
What to verify: Verify that every cross-boundary role has a named owner, a documented business purpose, and an explicit revocation path. If you cannot prove who can remove access within a defined time, the control plane is not yet ready for shared-cloud operations.
Decision rule: If a workload needs standing access across sensitivity tiers, treat that as an exception requiring tighter monitoring, narrower scope, and formal approval rather than as a normal deployment pattern.
Practitioner takeaway: The objective is not to make every workload identical, it is to make every access decision explainable, reviewable, and reversible across the shared environment.
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, 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 |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Shared-cloud identity control depends on tightly scoped access and account governance. |
| 8 — Audit Log Management | A unified identity plane must provide traceable access and revocation evidence. | |
| Recommendation — Enforce least privilege and review access paths for every IL4 and IL5 workload. Centralise logging for authentication, authorisation, and privilege changes. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | The question centers on consistent identity controls across shared-cloud workloads. |
| Recommendation — Standardise identity and access decisions across shared services and enclaves. | ||
| NIST SP 800-63 | IAL/AAL/FAL — Identity Assurance, Authenticator Assurance, Federation Assurance | Federated shared-cloud access needs assurance decisions for users and administrators. |
| Recommendation — Set assurance levels for sign-in and federation before extending access to mission workloads. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Boundary Protection | IL4 and IL5 workloads need explicit trust boundaries even in shared cloud. |
| Recommendation — Enforce segmented trust boundaries between workloads with different sensitivity levels. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding and Lifecycle Management | Shared cloud often exposes stale service and automation identities if lifecycle is weak. |
| NHI-03 — Excessive Permissions and Privilege Sprawl | Overbroad machine and service access is a central risk in shared-cloud identity design. | |
| Recommendation — Implement lifecycle controls to revoke non-human access promptly when roles change. Continuously reduce non-human privilege to the minimum required for each workload. | ||
Related resources from NHI Mgmt Group
- How can organisations tell whether identity-driven attacks are already moving through their cloud environment?
- Why do regulated organisations need to adjust identity and compliance assumptions when moving workloads into a sovereign cloud partition?
- How should organisations govern access to SAP workloads in RISE with SAP S/4HANA Cloud without weakening identity controls during migration?
- How should public sector agencies evaluate identity controls when moving workloads to the cloud?
