Notifications
Clear all
Topic starter
25/06/2026 3:08 pm
TL;DR: Policy-based IAM is presented as the answer to credential theft, entitlement creep, and audit pressure, with the source article citing 80% of cyberattacks using stolen credentials or identity-based methods and $4.45 million average breach costs. The deeper issue is that provisioning-only IAM assumes access state changes are enough, but modern identity risk lives in policy, privilege, and lifecycle control.
NHIMG editorial — based on content published by SafePaaS: policy-based IAM and the limits of provisioning-only security
By the numbers:
- In 2025, 80% of cyberattacks leverage stolen credentials or identity-based attack methods.
- Regulatory penalties average $4.45 million per incident.
Questions worth separating out
Q: How should security teams move beyond provisioning-only IAM?
A: They should treat provisioning as the account lifecycle layer and policy as the authorisation layer.
Q: Why does entitlement creep remain a problem in modern IAM programmes?
A: Entitlement creep persists because identities accumulate permissions faster than teams review and remove them.
Q: What breaks when organisations rely on IAM automation without policy governance?
A: Automation can make access faster, but it cannot decide whether access is appropriate.
Practitioner guidance
- Separate provisioning from authorisation policy Use provisioning to create and remove accounts, but enforce access decisions through a policy layer that can reject entitlements based on context, role, and risk.
- Inventory standing privileges across humans and NHIs Review groups, roles, API accounts, and service identities for access that remains valid only because no lifecycle or policy check has challenged it.
- Embed SoD validation before access activation Run segregation of duties checks before roles are assigned or changed, especially for ERP, finance, and administrative systems where conflicting access creates fraud exposure.
What's in the full article
SafePaaS's full article covers the operational detail this post intentionally leaves for the source:
- Workflow examples for automating provisioning and deprovisioning across HR, IT, and business systems
- Capability details for policy-based access control, including contextual rules and pre-access enforcement
- Audit and compliance features such as logging, dashboards, and evidence generation for regulated environments
- Implementation guidance for integrating IAM with hybrid infrastructure, SaaS platforms, and role change workflows
👉 Read SafePaaS's article on policy-based IAM for hybrid identity governance →
Policy-based IAM: what IAM teams need to fix beyond provisioning?
Explore further
25/06/2026 4:28 pm
Provisioning was built for access assignment, not for entitlement truth. The article exposes a common governance failure: organisations mistake the ability to create or revoke accounts for the ability to control risk. In practice, provisioning tools can accelerate access changes while leaving excess privilege, stale grants, and hidden third-party access untouched. The implication is that identity programmes must treat entitlement quality as a separate control domain, not a side effect of onboarding.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who is accountable when policy-based access controls fail?
A: Accountability sits with the identity, security, and business owners who define policy, approve exceptions, and accept residual risk. If access decisions are not tied to clear ownership and evidence, failures become hard to explain during audit, incident response, or regulatory review. Governance only works when someone owns the policy outcome.
👉 Read our full editorial: Policy-based IAM exposes the limits of provisioning-only security
