Dynamic authorization is falling behind remote-work access risk

At a glance

What this is: This is an analysis of why authentication alone is not enough and why dynamic authorization is becoming necessary for distributed access environments.

Why it matters: IAM teams have to govern access decisions after login across NHI, autonomous, and human identity programmes, or they will keep over-trusting static entitlements in fast-changing environments.

By the numbers:

• 62% of organizations offering remote work options ended up suffering from data breaches that could have been prevented if the employees had been coming into the office.

👉 Read PlainID's analysis of dynamic authorization for distributed access control

Context

Remote work has widened the gap between initial authentication and the continuous access decisions that follow it. In practice, organisations can no longer assume that a valid login session means the right level of access still holds for the rest of the interaction, especially when users move across cloud apps, legacy systems, and distributed policy stores.

This is an IAM and authorization problem before it is a visibility problem. RBAC and ABAC both become strained when policy logic is fragmented and access decisions must reflect role, context, device, time, and sensitivity in the same workflow. For human identity programmes, the question is no longer who logged in, but whether the entitlement still fits the moment.

Key questions

Q: How should security teams implement dynamic authorization in distributed environments?

A: Start by identifying the highest-risk applications and the policy decisions they still make locally. Then externalise those decisions into a centrally governed layer that can evaluate context such as role, device, location, and sensitivity at runtime. The goal is not more policy volume. It is fewer enforcement points and clearer ownership of access outcomes.

Q: Why does RBAC become harder to govern as environments become more distributed?

A: RBAC depends on stable roles, but distributed environments generate exceptions, temporary needs, and application-specific access patterns faster than role models can absorb them. That creates role explosion, inconsistent reviews, and weak visibility into who can do what. Once roles proliferate, least privilege becomes difficult to maintain and even harder to prove.

Q: What breaks when authentication is treated as the main security control?

A: Authentication only confirms identity at login. It does not continuously validate whether the subject should still have access after context changes. In practice, that leaves organisations exposed to stale entitlements, over-broad sessions, and access that remains valid long after the original trust decision should have been reconsidered.

Q: Who is accountable when dynamic authorization fails to stop inappropriate access?

A: Accountability sits with the teams that own access policy design, enforcement, and review, not just with the application team or the identity platform. If policies are fragmented across repositories or local application logic, the organisation has not created a governable control. Frameworks such as the NIST Cybersecurity Framework expect access governance to be owned and testable.

Technical breakdown

Why authentication does not complete the access decision

Authentication answers a narrow question: is this subject the one it claims to be. It does not answer whether the subject should be allowed to perform the requested action, on the requested resource, under the current risk context. In distributed environments, that distinction matters because identity assurance and authorisation drift can diverge quickly after login. Zero Trust architectures push this further by requiring continuous evaluation instead of one-time trust. When authentication is treated as the end of control, attackers and over-entitled users both inherit too much standing access.

Practical implication: treat authentication as an entry control and place real decision authority in runtime authorisation.

How RBAC and ABAC break under policy sprawl

RBAC scales poorly when organisations keep creating new roles for every exception, project, and application boundary. That produces role explosion, which makes review, maintenance, and least-privilege enforcement harder over time. ABAC improves flexibility by using attributes and policies, but it often ends up fragmented across lines of business and application teams. The result is not stronger governance, but inconsistent enforcement and too many places where access logic can drift. Dynamic environments need policy logic that can be evaluated centrally and applied consistently at runtime.

Practical implication: reduce role proliferation and measure how many policy sources still govern access outside a central control plane.

What policy-based access control changes in practice

Policy-based access control externalises authorisation so that business rules can be evaluated in real time instead of being hard-coded into each application. That matters because modern access decisions often depend on multiple signals at once, including certification level, sensitivity of the resource, device state, and location. Centralisation does not remove complexity, but it gives security teams one place to govern it. For organisations with many directories, repositories, and application-level rules, PBAC is less about convenience and more about keeping authorisation governable at scale.

Practical implication: externalise access logic where possible so policy updates do not require repeated application changes.

Threat narrative

Attacker objective: The attacker aims to move from a legitimate or stolen login to over-broad access that enables data theft at scale.

1. Entry occurs after a valid login grants access to a network, application, or system, even though the session may later be used in ways the original authentication did not anticipate.
2. Escalation follows when static roles or stale policies allow broader permissions than the current context justifies, letting the subject reach data or functions beyond the intended scope.
3. Impact is the theft of sensitive records, financial information, or other business-critical data, which creates both operational disruption and reputational damage.

Breaches seen in the wild

• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication is no longer the control boundary that matters most. This article shows how organisations still over-assign security weight to the login event, even though the real risk sits in what happens after authentication. In distributed environments, the decisive control is whether authorisation can adapt as context changes across the session. For human identity programmes, that means governance has to move from entry verification to runtime access decisions.

Role explosion is a governance failure, not an administrative inconvenience. RBAC becomes brittle when teams keep creating new roles to match business exceptions and application sprawl. That brittleness then drives inconsistent review, unclear ownership, and weak least-privilege enforcement. The implication is that access governance collapses when the organisation cannot keep its policy model aligned with how work actually happens.

Dynamic authorization is the right control pattern only when it is externally governable. PBAC is valuable because it makes policy decisions visible and centrally managed, but the real issue is whether the enterprise can actually maintain those policies across repositories, directories, and applications. Without central governance, “dynamic” can become another word for fragmented and opaque. Practitioners should treat runtime authorisation as a control architecture, not a feature request.

Remote work exposed a standing assumption that access can be judged once and trusted for the rest of the session. That assumption was designed for slower, more predictable access paths. It fails when users move across devices, locations, and applications while policy remains static. The implication is that modern IAM programmes must redesign how trust is re-evaluated after login, because the original approval point no longer reflects operational reality.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A further 47% have only partial visibility into those third-party connections, which leaves policy decisions and revocation workflows operating with incomplete identity context.
• For a broader control model, see The 52 NHI breaches Report, which shows how missing identity visibility turns into recurring exposure patterns.

What this signals

Policy sprawl is becoming an operating-model issue, not just an access-control issue. As organisations add more directories, applications, and exception paths, the number of places that can override central policy keeps rising. Teams should expect governance work to shift toward consolidating authorisation logic and proving that runtime decisions are still explainable.

Dynamic authorisation will increasingly be judged by its auditability as much as by its flexibility. If a policy engine cannot show why a decision changed, it will not satisfy security, audit, or compliance stakeholders for long. That makes traceability, policy ownership, and decision logging core programme requirements rather than optional extras.

With 1.5 out of 10 organisations highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security, the broader lesson is clear: identity governance is still lagging the pace of distributed access. Teams that want stronger control need to align authorization design with how access is actually consumed across humans, machines, and emerging agentic systems.

For practitioners

• Map where authorisation still lives inside applications Inventory applications, directories, and repositories that make local access decisions instead of consuming a central policy layer. Prioritise systems where role changes, exception handling, or manual approvals create the most drift between policy and enforcement.
• Measure role explosion before it obscures least privilege Count how many roles exist, how many are duplicates or near-duplicates, and how often new roles are created for one-off exceptions. Use that baseline to identify where RBAC has become ungovernable and where policy consolidation is needed.
• Externalise high-risk decisions into runtime policy checks Move sensitive access decisions away from static application logic and into centrally managed policies that can evaluate context such as device, location, and resource sensitivity at the moment of access.
• Rework reviews around decision quality, not login success Stop using successful authentication as a proxy for safe access. Review whether access decisions are re-evaluated after the session starts, and whether changes in context can actually reduce or revoke permissions.

Key takeaways

• Authentication alone does not secure distributed access, because the real control problem sits in runtime authorisation.
• RBAC and ABAC both weaken when policy sprawl outpaces governance, creating role explosion and inconsistent enforcement.
• Practitioners need centrally governed, auditable policy decisions if they want access control to remain usable at scale.

Key terms

• Dynamic Authorization: Dynamic authorization is the practice of making access decisions at the moment a request is made, using current context instead of relying only on a static role or prior login. It helps organisations reduce over-entitlement, but only when the policy logic is centrally governable and consistently enforced.
• Policy-Based Access Control: Policy-based access control is an authorisation model that evaluates business rules and contextual signals to decide whether access should be allowed. It is more flexible than fixed role models, but it only improves governance when policy ownership, auditability, and enforcement are aligned across the environment.
• Role Explosion: Role explosion happens when an organisation creates too many roles to handle exceptions, projects, or application-specific access needs. The result is a bloated model that is hard to review, difficult to maintain, and often too blunt to support least privilege effectively.
• Runtime Authorization: Runtime authorization is the decision process that determines access while a user or system is actively trying to use a resource. It matters because identity risk changes after authentication, and controls that do not re-evaluate access in context can quickly become stale.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by PlainID: Dynamic authorization and access management in distributed environments. Read the original.