Why do static IAM policies fall short for DORA obligations?

Why Static IAM Falls Short Under DORA

DORA is not asking institutions to prove they wrote access policies. It is asking them to sustain operational resilience while identity risk changes continuously. Static IAM policies assume the important variables are stable: device posture, location, session context, privilege scope, and user intent. In reality, those variables shift during the life of a session, and a policy that was safe at login can become unsafe minutes later.

This is why static rules create a false sense of control. They work for predictable requests, but they do not adapt well to behavioural drift, compromised sessions, or shifting operational pressure. Current guidance suggests that resilience depends on continuous evaluation, not annual or quarterly access certification alone. DORA’s expectations align more closely with runtime decisioning and identity governance that reacts to risk as it appears, which is also consistent with the NIST Cybersecurity Framework 2.0.

NHIMG research shows the scale of the problem: Ultimate Guide to NHIs — Regulatory and Audit Perspectives notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In practice, many security teams encounter identity failure only after access has already been abused, rather than through intentional resilience testing.

How It Works in Practice

For DORA-aligned environments, the practical answer is not simply tighter policy writing. It is moving from static entitlement models toward continuous, context-aware authorisation. That means evaluating access at request time using current signals such as device trust, workload posture, source network, session age, unusual behaviour, and the sensitivity of the action being attempted. The point is to decide whether access should continue, not just whether it was valid at the start.

Institutions typically combine several controls:

• Risk-based access decisions that can step up, limit, or revoke privileges mid-session.
• Short-lived credentials instead of persistent access where operationally feasible.
• Strong logging and traceability so access decisions can be explained during incident review.
• Segregation of duties for privileged workflows so one compromised identity cannot move freely across critical functions.

That direction is consistent with DORA — Digital Operational Resilience Act, which emphasises operational resilience rather than periodic compliance checklists. It also matches the lifecycle focus in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, where identity creation, rotation, offboarding, and review are treated as ongoing security operations rather than one-time events.

The operational logic is simple: if the identity is trusted only at login, the control is already behind the threat. These controls tend to break down in high-change environments such as cloud-native estates, outsourced operations, and machine-to-machine workflows because context changes faster than periodic policy reviews can react.

Common Variations and Edge Cases

Tighter runtime access control often increases operational overhead, requiring institutions to balance resilience against latency, change management, and investigation burden. That tradeoff is real, especially where business processes depend on uninterrupted access for payment processing, incident response, or customer support. Current guidance suggests that the answer is not maximum restriction everywhere, but calibrated restriction around critical paths.

There is no universal standard for this yet. Some organisations use coarse policy gates for lower-risk systems and finer-grained, continuous checks only for sensitive workloads. Others pair static role baselines with dynamic session controls. The important point for DORA is that static policies alone are usually insufficient where access conditions change after authentication.

One common edge case is exception handling. Emergency access, third-party maintenance, and privileged break-glass sessions need explicit time limits and post-use review, otherwise they become permanent backdoors. Another is distributed environments, where inconsistent identity governance across cloud, SaaS, and on-prem systems creates blind spots. NHIMG research on the Top 10 NHI Issues highlights how inconsistent lifecycle control and excessive privilege repeatedly undermine resilience. The practical lesson is that DORA compliance is weakened when access policy cannot keep pace with real-world operating conditions.

Related resources from NHI Mgmt Group

• Why do static access policies create problems for DORA compliance?
• Why do static role-based policies fall short in zero trust programmes?
• Why does broken access control persist even when IAM policies exist?
• How should teams manage Google Cloud IAM permissions when allow and deny policies use different formats?