TL;DR: Many breaches occur at authorization because valid authentication can still be followed by excessive access, privilege creep, and weak context checks across RBAC, ABAC, and multi-cloud environments, according to StrongDM. The real issue is not login success but whether access decisions stay tied to least privilege, auditability, and real-time conditions.
NHIMG editorial — based on content published by StrongDM: What Is Authorization? Types, Examples, and How It Works
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams implement authorization in multi-cloud environments?
A: Security teams should standardize policy definitions, logging, and decision points before distributing access across cloud and on-prem systems.
Q: Why do service accounts and API keys make authorization harder to govern?
A: Service accounts and API keys often outlive the task or system change that justified them, so authorization decisions become detached from current business need.
Q: What do organisations get wrong about least privilege in access control?
A: Many teams treat least privilege as a provisioning rule instead of a living authorization outcome.
Practitioner guidance
- Map every authorization model to a specific environment pattern Use RBAC for stable, role-dense environments, ABAC for high-context decisions, and continuous authorization where conditions change mid-session.
- Reduce standing access before adding more policy complexity Inventory long-lived entitlements for users, service accounts, tokens, and automation paths.
- Centralize authorization logs across cloud and on-prem systems Require one traceable record for identity, resource, context, and decision outcome across databases, Kubernetes, servers, and cloud services.
What's in the full article
StrongDM's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of how RBAC, ABAC, DAC, MAC, and CBAC differ in day-to-day enforcement.
- Practical examples showing how centralized policy enforcement works across databases, servers, Kubernetes, and cloud services.
- Implementation guidance for just-in-time access, policy-as-code, and access reviews in real environments.
- Detailed comparison of authorization and authentication using the Target breach as a concrete illustration.
👉 Read StrongDM's article on authorization models, examples, and least privilege →
Authorization and least privilege in cloud environments: are your controls keeping up?
Explore further
Authorization is the control plane where identity risk becomes operational risk. Authentication proves a subject is known, but authorization determines whether that subject can cause damage. The article correctly places the breach point after login, which is where NHI misuse, privilege creep, and weak policy boundaries tend to surface. Practitioners should treat authorization as the place where governance either holds or collapses.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing that revocation delay is still a governance weakness.
A question worth separating out:
Q: Who is accountable when authorization fails and data is exposed?
A: Accountability normally sits with the identity owner, the platform owner, and the governance function that approved or failed to revoke access. If third-party credentials are involved, the owning business relationship must also be part of the review. Authorization failures are governance failures, not just technical misconfigurations.
👉 Read our full editorial: Authorization in cloud environments needs continuous, contextual enforcement