Roles begin to preserve history instead of reflecting current need, which inflates access, confuses reviewers, and weakens remediation. Over time, the governance process certifies a design problem rather than correcting it. That is why role quality should be reviewed as a control issue, not just a modelling task.
Why This Matters for Security Teams
When role models are not maintained, the problem is usually not just extra permissions. The role itself starts to encode old projects, departed staff, and one-off exceptions, so reviewers approve an access pattern that no longer matches how work is actually done. That creates audit noise, slower remediation, and a false sense of control. It also makes incident response harder because access paths look “approved” even when they are no longer justified. Guidance from the NIST Cybersecurity Framework 2.0 treats access governance as an ongoing function, not a yearly cleanup exercise, and that mindset matters here. For NHI programs, stale role design can be just as risky as stale secrets, because it quietly expands who or what can act on behalf of the business. In practice, many security teams encounter role drift only after a review cycle has already certified the problem for several quarters. The State of Secrets in AppSec shows how quickly control gaps become operational debt when governance is left to decay.
How It Works in Practice
A maintained role model should describe current business functions, current systems, and current boundaries. When it does not, access reviews end up validating history instead of intent. That usually shows up in three ways: inherited entitlements that no longer map to a job, exceptions that become permanent, and role overlap that hides excessive access behind familiar names. For non-human identities, the same failure often appears as service roles that outlive the workload they were built for, or as shared roles that combine unrelated privileges for convenience.
Practically, teams should treat role maintenance as a control operation with clear triggers:
- Review roles when applications, teams, or data classifications change.
- Retire roles with no active owners or no recent legitimate use.
- Split broad roles when different tasks require different trust levels.
- Compare current entitlements against actual access logs, not just org charts.
- Use exceptions with expiry dates, not open-ended approvals.
This is where Schneider Electric credentials breach and similar cases matter as cautionary signals: once access paths become difficult to explain, they become difficult to defend. The right benchmark is whether a reviewer can understand why the role exists today, not whether it was reasonable when first created. Control expectations in NIST Cybersecurity Framework 2.0 align well with this approach because they emphasize continuous governance and risk-based validation. These controls tend to break down in fast-moving environments with frequent team reorgs, shared admin models, or legacy applications that cannot support clean role decomposition.
Common Variations and Edge Cases
Tighter role maintenance often increases operational overhead, requiring organisations to balance cleaner governance against delivery speed and reviewer fatigue. That tradeoff is real, especially where multiple product lines, acquired systems, or shared infrastructure teams use different naming conventions and ownership models. Current guidance suggests that the answer is not to relax role governance, but to reduce model complexity so reviews stay meaningful.
One common edge case is “good enough” role reuse across similar teams. That can work temporarily, but only if the shared scope is explicit and periodically revalidated. Another is emergency or break-glass access, which should not be folded into standard roles because it distorts review outcomes. In environments with many secrets-bearing workloads, stale roles can also obscure where credentials are actually used, which increases the chance that an old entitlement survives long after the associated system has changed. The broader lesson from The State of Secrets in AppSec is that governance fails fastest when control ownership is diffuse and exceptions accumulate. There is no universal standard for role recertification cadence, but best practice is evolving toward event-driven review plus periodic deep cleanup rather than calendar-only certification.
