They should review decision ownership, exception handling, onboarding flows, and how access reviews will be run across the group. The key question is whether one governance model can support multiple operational environments without creating ambiguity about who approves, who supports, and who is accountable.
What to review before expanding shared access across trusts
Before broadening shared access, identity leaders should treat the trust boundary as the real design problem, not just the permission set. The decision has to stand up across multiple operational environments, with clear ownership for approvals, exceptions, onboarding, and recurring access review. If those responsibilities blur, the governance model becomes harder to run than the access model it is meant to control.
Shared access across trusts often fails when the governance process is assumed to be the same everywhere but the operating reality is not. One environment may have stronger support coverage, different review cadence, or a different approval chain. The question is whether the proposed model can handle that variation without creating ambiguity about who can grant access, who can challenge it, and who carries the residual risk.
That makes the pre-expansion review less about technical enablement and more about operating discipline. If the same access path is going to cross trust boundaries, the organisation should be able to answer who owns the relationship, how exceptions are time-bound, and how onboarding and offboarding will work when one environment changes faster than the others.
One practical reference point is to compare the proposal against established identity lifecycle and access governance patterns in the IAM and IGA Basics guide. The same governance logic also shows up in the Access Reviews and Certification Guide, which is useful when the review process must work across more than one operating model.
Where shared access governance usually breaks down
The biggest failure mode is not the trust relationship itself, it is inconsistent decision-making around it. Shared access can look efficient on paper, but if approval authority differs by environment, the same request may be handled differently depending on where it lands. That creates drift in accountability, and once exceptions begin to accumulate, the exception process can become the de facto policy.
Another common weakness is poor onboarding design. If access provisioning across trusts depends on informal coordination, the organisation may end up granting access before ownership, review cadence, and support expectations are fully established. The same problem appears at offboarding, where access removal can stall because no one owns the cross-trust dependency end to end.
This is why shared access should be reviewed as an access governance problem first and an operational convenience second. The most useful question is not whether access can be shared, but whether the business can still prove who approved it, who is responsible for support, and how access will be revalidated after role, team, or system changes.
The strongest internal controls for this topic are the ones that make lifecycle and review obligations explicit. The NHI Lifecycle Management Guide is relevant here because it ties provisioning, rotation, offboarding, and access review into one operating model rather than treating them as separate tasks.
What good looks like before you expand the model
A sound pre-expansion review should produce a simple answer set: who owns the trust, who can approve shared access, what exceptions are allowed, how onboarding is completed, and how reviews will be run across the group. If those answers differ by environment, the differences should be explicit and documented, not discovered after the first access issue or audit challenge.
Practitioners should also verify that the review process is actually runnable at scale. A governance model that depends on tribal knowledge or one expert approver may work for a pilot, but it will usually fail once shared access becomes routine. The practical test is whether the process can survive staff turnover, support handoffs, and a higher volume of exceptions without losing clarity.
That is where the broader governance model matters. The Top 10 NHI Issues resource is useful because it highlights how ownership gaps, excessive permissions, and shared account patterns turn into recurring governance problems when they are not designed out early.
Risk and Threat Considerations
Shared access across trusts increases exposure when approval paths, review ownership, or support responsibilities are unclear. The risk is not only overprovisioning, it is also accountability failure: access can remain in place longer than intended, exceptions can become permanent, and no one has a reliable basis for challenge or removal.
Failure mechanism: Cross-trust access is granted through inconsistent workflows or unclear delegated authority, then persists because onboarding, review, and exception handling are not owned by a single accountable model.
Impact: Excess access, delayed revocation, audit friction, and a larger blast radius if a shared trust path is misused or compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Shared access should stay bounded to only the access needed across trusts. |
| IA-5 — Authenticator Management | Cross-trust access depends on controlled credential lifecycle and revocation. | |
| AC-2 — Account Management | The question is about governance over who gets access, who approves, and who owns exceptions. | |
| Recommendation — Limit cross-trust shared access to the minimum permissions required and review exceptions regularly. Track, rotate, and revoke shared credentials under a defined lifecycle owner. Define account ownership, approval authority, and revocation responsibility before expanding access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Shared access across trusts is fundamentally an access-control governance decision. |
| A.5.18 — Access rights | The answer centers on review, exception handling, and ongoing access governance. | |
| Recommendation — Document access rules and approval paths for every trust relationship. Review and recertify shared access rights on a defined schedule across all environments. | ||
Practitioner Guidance
What to prioritise: Lock down decision ownership before broadening access. If the approval model is ambiguous, the expansion should pause until each trust has a named owner for approvals, exception handling, and recurring review.
What to verify: Confirm that onboarding and access review operate the same way across all environments that will share the trust. A model is not ready if it only works when one team manually coordinates every case.
Common mistake: Treating shared access as a permissions change instead of a governance change. If the operating model is not updated at the same time, the trust boundary becomes harder to explain and harder to defend.
Practitioner takeaway: Expand shared access only when the organisation can prove that accountability, exception handling, and recertification remain unambiguous across every environment involved.
Related resources from NHI Mgmt Group
- Should organisations prioritise cloud identity governance before expanding privileged access controls across applications?
- How should ICS leaders assess digital identity maturity before trying to standardise access across connected NHS organisations?
- When should organizations review access controls?
- Who should own AI agent governance when identity and access are shared across teams?