How should organisations govern access when shared workflows span multiple trusts or sites?

Why This Matters for Security Teams

Shared workflows are where identity governance becomes operationally messy. A single business process may span multiple trusts, sites, or partner organisations, yet the record model is still shared. If each site invents its own roles, device checks, approval steps, and exception paths, access stops being a governed model and becomes a patchwork of local customs. That creates inconsistent privilege, weak auditability, and hard-to-revoke access across the workflow boundary. The NHI risk is familiar too: NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.

For security teams, the issue is not whether local variation exists, but whether it is constrained by one common access policy and one shared evidence model. Guidance from NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward standardised, least-privilege access with strong accountability. In practice, many security teams discover the control gap only after one site has already granted a broader entitlement that quietly propagates through the shared workflow.

How It Works in Practice

The governing pattern is to define a common access model first, then allow only approved local overlays. Start by separating what is truly global from what is site-specific: record access, workflow state transitions, and shared service actions should be controlled centrally; local device checks, approval chains, and regulatory constraints can vary only if they do not change the underlying entitlement pattern. That means the same identity should mean the same baseline access everywhere, even when the route to approval differs.

In practical terms, organisations should document one canonical role or attribute set for the workflow, map each local trust to that model, and enforce policy at runtime rather than by ad hoc approvals. This is where Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and 52 NHI Breaches Analysis are useful references: lifecycle ownership, rotation, and revocation need to follow the shared workflow, not the local site boundary. A workable implementation usually includes:

• one shared entitlement catalogue for the workflow;
• site-level exceptions with expiry dates and named owners;
• JIT access for elevated actions instead of standing privilege;
• central logging that shows which trust approved which action;
• periodic recertification against the common model, not local preference.

When access involves service accounts, API keys, or workflow automation, the same logic applies: credentials should be scoped to the shared task, not copied per site. This aligns with Zero Trust expectations in both NIST and NHI governance, where access is continuously checked rather than assumed from network location alone. These controls tend to break down when a federated platform allows each site to mint its own bespoke roles, because the shared record model no longer maps cleanly to one entitlement inventory.

Common Variations and Edge Cases

Tighter central governance often increases coordination overhead, so organisations need to balance operational speed against control consistency. Not every local variation is bad. There is no universal standard for this yet, but current guidance suggests allowing local differences only when they are clearly bounded, documented, and technically unable to expand privilege beyond the common model.

Two edge cases matter most. First, cross-border or multi-regulator environments may require different approval evidence, retention rules, or data access restrictions. Second, legacy trusts may not support the same identity protocol or attribute schema. In both cases, the answer is not to create a new role universe per site, but to wrap the local difference inside a shared control plane and a shared audit trail. The Top 10 NHI Issues and Ultimate Guide to NHIs — Regulatory and Audit Perspectives both reinforce the need for visibility and defensible evidence across the full identity lifecycle.

Where workflows are highly autonomous, policy design should also consider workload identity and intent-based approval rather than static RBAC alone. That is especially important when a service or agent can act across multiple sites without a human in the loop. The right question is not “which site owns this access?” but “what shared business action is authorised, under what context, and for how long?”

Related resources from NHI Mgmt Group

• How should health systems govern shared care record access across multiple sites?
• How should organisations govern eSignature workflows as identity events?
• How should security teams govern access on shared devices in manufacturing environments?
• How should security teams govern non-human identities that have persistent access?