Tailor made entitlements create risk because they are hard to scale, difficult to review consistently, and easy to lose track of as people move across functions. When access is assembled one person at a time, administrators are more likely to miss toxic combinations, duplicate permissions, and outdated access that no longer matches the person’s current job.
Why identity-by-identity entitlements become hard to govern
Tailor made access starts out looking precise, but the model breaks down when every grant is bespoke. Each exception creates another rule to remember, another approver to consult, and another path an auditor must reconstruct. Over time, the access model becomes a collection of one-off decisions rather than a manageable policy, which is why it is so hard to keep consistent as roles, systems, and job functions change.
That problem is usually not the entitlement itself, but the operating model around it. A person-specific grant may be justified today and wrong next quarter, especially when changes in function, project, or environment are not translated into corresponding access changes. The more access is assembled individually, the more the organisation depends on memory, informal knowledge, and manual review to keep it accurate.
For access governance to stay understandable, the entitlements need some shared structure. A useful baseline is to compare bespoke grants against role patterns, IAM and IGA Basics, and expected joiner-mover-leaver change so that exceptions remain deliberate instead of becoming the default.
What goes wrong when access is managed one person at a time
Identity-by-identity administration tends to create privilege creep, duplicate permissions, and hidden conflicts. When administrators assign access by request rather than by standard entitlement design, they often solve the immediate need but leave behind overlap with existing permissions, stale access from an earlier job, or combinations that are unsafe only when viewed together. That is how toxic combinations slip through review.
This approach also makes scale the core failure. A few exceptions are manageable; hundreds of bespoke grants are not. Reviewers have to compare each person’s access against different business contexts, which increases the chance of rubber-stamping. The organisation may still believe it has access governance, but in practice it is operating with fragmented records and inconsistent judgement.
Lifecycle discipline helps, because one-off entitlements are far more likely to be forgotten when people move. NHI Lifecycle Management Guide is useful here because it treats provisioning, rotation, offboarding, and visibility as connected control points rather than separate chores.
Role structure also matters because bespoke access often appears where the organisation has not defined reusable patterns well enough. Role Mining and Role Design Guide supports the idea that a sustainable access model needs a manageable catalogue, not endlessly custom grants.
Why bespoke entitlements increase review, audit, and control risk
Custom access is difficult to certify because there is no stable reference point. Reviewers have to judge each grant in isolation, so the question becomes “Does this still look reasonable?” instead of “Does this match an approved access pattern?” That weakens review quality and makes it easier for outdated or excessive access to survive recertification.
Bespoke entitlements also make separation-of-duties checks harder. The risk is not only excessive privilege, but the inability to see when individually reasonable permissions combine into an unacceptable outcome. Segregation of Duties (SoD) Guide is directly relevant because toxic combinations are often missed when access is distributed across many manual decisions.
Operationally, this is where access reviews lose value. The more unique the entitlement set, the more time reviewers spend interpreting context and the less time they spend removing access. Access Reviews and Certification Guide addresses that review fatigue problem by focusing on removal, context, and closed-loop remediation.
For broader governance, the issue is not only security. Bespoke access is harder to explain, harder to prove, and harder to reconcile after a move or exit. Once the access model depends on exceptions, the review process becomes an exception management exercise instead of a control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Tailor-made entitlements often drift into excessive access. |
| AC-2 — Account Management | Identity-by-identity access must still be provisioned, reviewed, and removed consistently. | |
| AC-5 — Separation of Duties | Custom grants can hide toxic combinations across multiple permissions. | |
| Recommendation — Enforce least privilege and remove any entitlement that is not clearly necessary. Standardise account lifecycle handling and recertify bespoke access on a fixed cadence. Check bespoke entitlements for conflicting access before approval and during review. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Bespoke entitlements need policy-backed access rules to stay governable. |
| A.5.18 — Access rights | Access rights must be provisioned, reviewed, and removed as people change roles. | |
| Recommendation — Define access rules that limit exceptions and keep entitlement decisions consistent. Review access rights against current job need and revoke outdated permissions promptly. | ||
Practitioner Guidance
What to prioritise: Reduce the number of one-off entitlements before you try to perfect review quality. If a grant is frequently repeated, convert it into a role or pattern; if it is truly unique, make the business justification explicit and time bound.
What to verify: Check whether each bespoke entitlement has an owner, an expiry or review trigger, and a clear reason it cannot be expressed as a standard access pattern. If those answers are missing, the entitlement is already too fragile to trust.
Common mistake: Treating a custom grant as “safe” because it was approved. Approval proves only that someone needed it once, not that the access remains appropriate after movement, reorganisation, or accumulation of other rights.
Practitioner takeaway: The real risk is not custom access by itself, but custom access that has no lifecycle, no reusable pattern, and no reliable way to expose overlap with everything else the person already has.
