Berechtigungskonzepte sind die Basis für auditierbare Zugriffe

At a glance

What this is: This is an analysis of how a formal permission concept creates auditable access governance, with the key finding that unclear roles and weak offboarding drive overprovisioning and compliance risk.

Why it matters: It matters because IAM teams have to govern the same access principles across human users, privileged accounts, and NHIs, and permission concepts fail when lifecycle, review, and enforcement are not tied together.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Imprivata's guidance on building audit-ready permission concepts

Context

A berechtigungskonzept is the governance layer that defines who can access what, when, and under which conditions. In practice, that means the real control is not the role model alone but the linkage between approval, provisioning, review, and removal across the identity lifecycle.

The article frames this as a compliance and security foundation for regulated environments, especially where access must be auditable under DSGVO requirements and where privileged access needs tighter handling. The core gap is familiar to IAM and PAM teams: if rights are broad, undocumented, or not removed on time, the concept exists on paper but not in operational control.

That problem is not limited to human users. The same lifecycle logic now has to cover service accounts, tokens, and privileged workflows, which makes entitlement design and offboarding a shared governance issue across the identity estate.

Key questions

Q: How should security teams build a permission concept that actually reduces risk?

A: Start with actual business tasks, map them to narrow roles, and separate standard access from exceptions. Then tie approval, provisioning, review, and removal into one lifecycle process so access does not drift away from the current job state. A permission concept only reduces risk when it stays aligned to how the organisation really works.

Q: Why do broad roles and undocumented exceptions create governance risk?

A: Broad roles hide privilege excess inside apparently normal access, while undocumented exceptions prevent consistent review. Together they make it difficult to prove least privilege or explain why a user, account, or workload still needs access. That is why entitlement sprawl becomes both a security issue and an audit issue.

Q: How do organisations know whether access reviews are working?

A: Access reviews are working when they lead to timely removals, reduced exception volume, and role definitions that stop accumulating unused rights. If the same accounts keep reappearing with the same excess access, the review process is only producing paperwork. Evidence of change is the real success signal.

Q: Who is accountable when privileged access is not removed on time?

A: Accountability should sit with the business owner of the role, the system owner, and the identity governance process that approved and failed to remove the access. In regulated environments, delayed removal is not just a technical issue. It is a control failure that can undermine auditability and compliance evidence.

Technical breakdown

Rollenmodelle and least privilege in entitlement design

A permission concept works by translating business tasks into roles and then binding those roles to specific access rights. The technical goal is to reduce direct person-to-permission assignment, because that pattern scales badly and creates review noise. Least privilege only works when the role is narrow enough to reflect actual job function, and when exceptions are explicitly separated from baseline access. Function separation is part of the control logic, not an optional add-on. When roles become broad catch-alls, the model still looks structured, but the effective privilege set drifts upward.

Practical implication: define roles from actual task boundaries, not organisational hierarchy, and review any role that mixes read, write, and admin access.

Lifecycle control across joiner, mover, leaver events

The article correctly treats a permission concept as a living control, not a one-time document. Joiner, mover, and leaver processing is what keeps the access model aligned to current duties. If role changes are not mirrored in provisioning and deprovisioning, the organisation accumulates stale access that survives beyond necessity. That is the point where governance stops being preventative and becomes forensic. Auditability depends on being able to show who approved a right, when it was granted, and when it was removed.

Practical implication: tie every role change to a lifecycle event and require removal evidence for access that no longer matches the current job state.

Audit trails, recertification, and privileged access enforcement

Auditability is the proof layer for a permission concept. Without change logs, approval history, and periodic review, the organisation cannot demonstrate that access remained appropriate over time. For privileged accounts, the control bar is higher because session impact is larger and misuse is harder to absorb. MFA, session monitoring, and recertification all serve the same governance purpose: they reduce the chance that elevated access becomes invisible or permanent. In regulated environments, that evidence trail is part of the control, not just documentation after the fact.

Practical implication: treat recertification and privileged session oversight as mandatory evidence controls, not administrative housekeeping.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

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

NHI Mgmt Group analysis

Berechtigungskonzepte are only effective when access is treated as a lifecycle control, not a static policy. The article shows the right governance instinct, but the deeper lesson is that roles, approvals, and revocation have to move together. If provisioning is controlled but offboarding is weak, the concept does not reduce risk, it redistributes it into stale entitlements and audit gaps. Practitioners should read this as a lifecycle governance problem, not a documentation exercise.

Overprovisioning is the named failure mode that turns permission concepts into compliance theatre. The article points to broad roles, undocumented exceptions, and missing reviews as common mistakes, which is exactly how access drift accumulates. Once permissions outgrow actual duties, the organisation loses both least privilege and credible auditability. The practical conclusion is that role design must be constrained enough to survive review.

Least privilege is strongest when it is enforced across human access, privileged access, and non-human identities. IAM and PAM teams often treat these as separate programmes, but the control objective is the same: narrow access, prove it, and remove it when it is no longer needed. The cross-domain lesson is that permission concepts become more resilient when lifecycle and evidence standards are shared across all identity types.

Auditability is not a reporting feature, it is the operating proof that a permission concept still exists in practice. A concept that cannot show approvals, changes, and recertification outcomes is not governable at scale. That becomes more serious in KRITIS and healthcare contexts, where documentation and traceability are part of the control expectation. Practitioners should treat evidence quality as a design requirement from the start.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, which is why entitlement cleanup must be treated as a control, not a follow-up task.
• For the lifecycle angle, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for how governance and revocation fit together.

What this signals

Entitlement sprawl: permission concepts will be judged less by how well they are documented and more by whether they actually collapse excess access over time. In mixed estates, that means one governance model has to cover human roles, privileged accounts, and service identities without weakening review discipline.

The pressure point is no longer just initial provisioning. As cloud, SaaS, and delegated access expand, organisations need evidence that rights are removed as reliably as they are granted, otherwise access reviews become a reporting ritual rather than a control.

For teams formalising this work, the strongest reference point is NIST Cybersecurity Framework 2.0, because it connects identity governance to protection, detection, and response expectations.

For practitioners

• Define narrow role boundaries Build roles from actual task sets, not departments or job titles, and separate read, write, and admin rights wherever possible. Use exception handling only for documented edge cases.
• Bind access changes to lifecycle events Require provisioning and removal actions to follow joiner, mover, and leaver triggers so rights do not outlive the identity state that justified them.
• Make recertification evidence operational Track approval history, role changes, and removal records in a form that auditors can verify without reconstructing intent from tickets or spreadsheets.
• Apply stronger controls to privileged access Use MFA, session oversight, and tighter review cadence for accounts with elevated rights so administrative access does not become standing access by default.

Key takeaways

• A permission concept only works when it governs role design, lifecycle change, and revocation as one control system.
• The main failure mode is overprovisioning, which turns clean-looking role structures into hidden access drift and weak audit evidence.
• Practitioners should focus on narrow roles, mandatory removal triggers, and evidence-rich recertification before expanding scope.

Key terms

• Berechtigungskonzept: A permission concept is the governance model that defines who may access which systems, data, or functions, and under what conditions. In mature practice, it links role design, approvals, provisioning, review, and revocation so access remains traceable and defensible across the identity lifecycle.
• Least Privilege: Least privilege is the principle that each identity receives only the access required to perform its current task. For humans, service accounts, and autonomous systems alike, the practical test is whether excess rights are prevented at design time and removed promptly when no longer needed.
• Rezertifizierung: Recertification is the periodic review of access rights to confirm they still match business need and policy. It is not a paperwork exercise when done properly. It is the evidence mechanism that shows whether permissions remain valid, especially for privileged and long-lived access.
• Rollenbasiertes Zugriffskonzept: A role-based access concept groups permissions into roles instead of assigning them directly to individuals. This makes governance easier to scale, but only if roles stay narrow, exceptions are controlled, and the model is continuously cleaned up as business responsibilities change.

Deepen your knowledge

Berechtigungskonzepte, least privilege, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model that has to work across roles, accounts, and audits, it is worth exploring.

This post draws on content published by Imprivata: Berechtigungskonzepte as the basis for secure and auditable access. Read the original.