How do teams decide which access should be auto-granted and which should be requested?

What belongs in the auto-grant baseline?

Auto-granted access should be the smallest stable set that is shared by a clearly defined cohort and needed for ordinary work. That usually means access you can describe in policy without exceptions, individual judgment, or frequent case-by-case review. If the entitlement only fits some members of the cohort, or it depends on context that changes often, it is not a good auto-grant candidate.

The key test is whether the access can be treated as a default entitlement rather than a negotiated exception. Stable baseline access is easier to understand, audit, and explain to managers and auditors because the policy logic is explicit and repeatable. A good auto-grant rule reduces friction without hiding privilege decisions inside a vague role label.

In practice, teams usually separate “everyone in this cohort needs it” from “some people in this cohort need it sometimes.” The first category is suitable for automatic assignment; the second belongs in a request path because the business justification matters and the decision may vary by person, project, or system.

When should access move to request and approval?

Anything ambiguous, sensitive, or role-specific should be requested rather than auto-granted. That includes access with broader blast radius, access that crosses duties or environments, and access where the approver needs to make a judgment about business need, segregation, or risk. Request workflows keep those decisions visible instead of burying them in provisioning logic.

Request-based access also gives teams a clean place to handle exceptions. If an entitlement is only appropriate for a subset of the cohort, or only after a manager, system owner, or security reviewer agrees, it should not be part of the default package. This makes the access model easier to explain and prevents “baseline” from slowly absorbing special cases.

Teams often use the request path for elevated access, temporary access, access tied to sensitive data, and access that should expire or be reviewed more often than standard entitlements. In those cases, the control is not just approval itself, but the fact that the approval record proves why the access existed at all.

How do teams keep the boundary between the two clean?

The boundary works best when it is written as a decision rule, not a vague principle. A practical rule is: if the access is universal for the cohort, stable over time, and easy to defend in policy, auto-grant it; if any of those conditions fail, require a request. That keeps entitlement design consistent across teams and reduces ad hoc exceptions.

Good teams also review baseline access periodically to see whether a requested entitlement has become common enough to standardise, or whether an auto-granted entitlement has drifted beyond its original purpose. That review matters because access models tend to expand quietly unless someone challenges whether the entitlement still fits the cohort.

Where the business needs speed, the usual mistake is to widen the auto-grant set too far. A faster onboarding experience is useful, but not if it removes the ability to distinguish ordinary access from exceptional access. If the access decision needs human judgment to remain defensible, it should stay in the request flow.

Risk and Threat Considerations

When baseline access is defined too broadly, users accumulate standing privilege they do not consistently need, which increases exposure if an account is misused or compromised. When the request path is too broad, teams can also lose visibility into why sensitive access was granted and whether it still makes sense.

Failure mechanism: Overly generous auto-grants convert exceptions into defaults, which makes privilege creep harder to spot and weakens review quality. If requests are used for everything, approvals become noisy and the genuinely sensitive cases are easier to miss.

Impact: The organisation ends up with more standing access than intended, less defensible access decisions, and a weaker audit trail for who received what and why.

Practitioner Guidance

What to prioritise: Start by defining the cohort, then list only the access that every member of that cohort truly needs on day one. Everything else should default to request, especially when the entitlement is sensitive, temporary, or dependent on a manager or system owner’s judgment.

What to verify: Check that the auto-grant set can be explained in plain policy language without naming individuals or one-off cases. If the entitlement description needs frequent exceptions to make sense, it is probably not baseline access.

Decision rule: If removing the access from one person in the cohort would be hard to justify, it may be baseline. If granting it to the whole cohort would be hard to justify, keep it in the request flow.

Practitioner takeaway: The right split is not “low risk versus high risk,” but “stable cohort default versus judgment-based exception.” The clearer that line is, the easier it is to automate without losing control.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams prioritise NHI remediation in cloud environments?