Should access modelling rely on entitlement data alone?

Why This Matters for Security Teams

entitlement data is a useful starting point, but it is not a reliable model of real access demand. It shows what has been assigned, not what is actually exercised, and that gap can hide stale permissions, inherited access, and overprovisioned roles. In NHI environments, that matters because secrets and service accounts often persist far longer than the workload that originally needed them. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly why entitlement-only modelling tends to overstate entitlement as necessity.

This is also why access modelling should be paired with observed activity and context from runtime systems. The OWASP Non-Human Identity Top 10 treats overprivilege, weak lifecycle controls, and secret sprawl as core risk drivers, not edge cases. Teams that rely only on directory exports or cloud IAM reports often design roles around theoretical ownership instead of actual use, which weakens least privilege and creates cleanup backlogs. In practice, many security teams discover the mismatch only after access reviews, incidents, or failed deprovisioning attempts, rather than through intentional design.

How It Works in Practice

A stronger model starts by combining entitlement data with activity evidence. Entitlements tell you what a workload, service account, or agent could do on paper. Activity data shows what it actually did over a defined window, such as API calls, database queries, queue access, or secret retrieval. That comparison helps separate legitimate business function from dormant access.

Practitioners usually build the model in three layers:

• Inventory the assigned permissions, group membership, and policy attachments for each NHI.
• Collect runtime telemetry from cloud logs, identity providers, workload platforms, and secret managers to see exercised access.
• Map recurring activity back to a role or policy pattern, then flag permissions that are never used or are only used in exceptional cases.

This approach aligns with the Ultimate Guide to NHIs — Key Research and Survey Results, which highlights how common excessive privileges and poor visibility are across NHI estates. It also matches the direction of the OWASP Non-Human Identity Top 10, where visibility and lifecycle hygiene are treated as prerequisites for secure governance. For example, a CI job may inherit broad repository access but only ever read one artifact bucket; modelling on activity lets teams shrink the role without breaking the pipeline.

Current guidance suggests using activity context as a decision aid, not an automatic source of truth. Some permissions will remain unused simply because they are emergency or failover paths, so analysts should validate exceptions with owners before removal. These controls tend to break down in highly bursty environments, such as ephemeral build systems and multi-tenant data platforms, because short-lived jobs can look inactive unless the observation window is tuned to the workload’s real lifecycle.

Common Variations and Edge Cases

Tighter access modelling often increases operational overhead, requiring organisations to balance cleaner roles against more data collection and review effort. That tradeoff becomes sharper when workloads are ephemeral, auto-scaled, or delegated across services and agents. In those environments, a permission may appear unused simply because the workload runs intermittently or because the action is triggered only during incident recovery.

There is no universal standard for how much activity history is enough. Some teams model 30 days, others 90 or more, depending on release cadence and business criticality. Best practice is evolving, but the practical rule is to avoid deleting entitlements that support rare but legitimate workflows unless there is corroborating evidence from owners, runbooks, or change records. That is especially important for break-glass access, cross-account automation, and vendor-operated integrations.

The biggest error is treating entitlement data as if it proves necessity. It does not. A better governance pattern is to use entitlements to define the possible access surface, then use observed activity to confirm or refute that surface over time. That distinction improves role design, helps with recertification, and makes offboarding decisions more defensible.

Related resources from NHI Mgmt Group

• What breaks when access reviews rely on stale entitlement data?
• Why do access management and MFA fail to solve entitlement risk?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?