Why do organisations struggle to apply the same access model across different industries?

Why This Matters for Security Teams

Organisations struggle because access control is not just a policy choice, it is an operating-model choice. A bank, a hospital, a factory, and a public agency each expose different identity surfaces, workflow constraints, and evidence requirements, so a single entitlement model tends to fit none of them well. That is why identity design has to reflect business context, not just technology labels. NHI Mgmt Group’s Ultimate Guide to NHIs shows how quickly non-human identities multiply and become difficult to govern at scale.

The practical problem is that the same access model can mean very different things across sectors. In one environment, periodic review and broad role grouping may be acceptable because the systems are stable. In another, the same approach creates excessive standing privilege, weak evidence trails, or unusable controls that operators bypass. Current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls points to the same principle: least privilege must be enforced in a way the environment can actually sustain. In practice, many security teams discover this only after a role has been overextended across systems and the cleanup becomes an incident response exercise rather than a design decision.

How It Works in Practice

Most mature programmes start by separating the control objective from the enforcement pattern. The control objective is consistent: limit access, prove legitimacy, and remove it when no longer needed. The enforcement pattern changes by industry. In healthcare, access often needs to reflect patient-safety workflows and auditability. In manufacturing, it may need to account for OT systems, vendor maintenance windows, and fragile legacy interfaces. In government, evidence retention and segregation of duties may matter more than convenience. The same RBAC structure can exist in all three, but the role definitions, approval chains, and review cadence should not be identical.

For NHI and agent-driven access, the variation is even sharper. Static roles assume predictable behaviour, but autonomous agents and service workloads often act across multiple tools, APIs, and data stores in ways that are only known at runtime. That is why current guidance increasingly favours workload identity, policy-as-code, and just-in-time access over fixed long-lived entitlements. The Ultimate Guide to NHIs — Key Challenges and Risks and the 52 NHI Breaches Analysis both reinforce that visibility, rotation, and offboarding are where generic models fail first.

• Use workload identity to prove what the non-human actor is before issuing access.
• Prefer short-lived secrets and JIT credentials for tasks that do not need persistent access.
• Set policy at request time, not only at onboarding time, so context can shape the decision.
• Review entitlements by system criticality and regulatory burden, not by a single enterprise cadence.

Where possible, map access to actual business workflows rather than to generic job functions. These controls tend to break down in hybrid environments with legacy applications and third-party integrations because the same identity often has to satisfy incompatible enforcement methods.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance stronger assurance against speed, uptime, and support burden. That tradeoff is especially visible in highly regulated or mixed-technology environments, where one model may be secure on paper but too rigid for day-to-day operations. In those cases, current guidance suggests a risk-based design rather than a universal template.

There is also no universal standard for how much model uniformity is enough. Some teams standardise the control framework while allowing local variations in implementation. Others standardise the identity primitive and let each business unit define policy thresholds. Both can work, but only if the exceptions are explicit and reviewed. For example, a factory partner account might need stronger segmentation than a back-office SaaS integration, while a clinical system may need stricter evidence retention than either.

The key edge case is vendor and third-party access. External connections often sit across multiple trust boundaries, so the same access model breaks down when a partner uses shared credentials, opaque tooling, or inconsistent rotation discipline. NHI Mgmt Group’s Microsoft SAS Key Breach illustrates how quickly a single credential type can become a cross-environment exposure point when governance is too generic. Sector-specific access models are therefore less about inconsistency and more about matching control strength to operational reality.

Related resources from NHI Mgmt Group

• Why do organisations struggle to govern dynamic authorisation without a central access view?
• Why do organisations struggle with access reviews and entitlement analysis at scale?
• How should healthcare organisations govern access to patient data across applications and privileged workflows?
• How should organisations govern AI-driven physical access workflows across HR, IT, and security teams?