How should IAM teams decide which entitlements should stay birthright and which should move to JIT?

Use risk, not habit, to separate the two. Low-impact collaboration tools can stay in a baseline model if the business need is stable, while sensitive systems should move to time-bound, approval-based access. Reassess the split regularly, because a low-risk application can become high-risk as its data or permissions change.

Why This Matters for Security Teams

The birthright versus JIT decision is really an access-risk decision, not an HR convenience decision. Birthright entitlements are acceptable only when the business use is stable, low impact, and easy to monitor. Once an entitlement can touch sensitive data, production controls, or privilege escalation paths, static access becomes hard to defend. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is why entitlement creep matters so much in practice.

The mistake most IAM teams make is treating “everyone in this role gets this access” as a permanent truth. That works for predictable collaboration tools, but it breaks down for systems where a single entitlement can unlock secrets, admin functions, or downstream automation. The better lens is whether the access can be justified continuously, not merely once at onboarding. That aligns with the risk-based approach reflected in the NIST Cybersecurity Framework 2.0.

In practice, many security teams discover excessive birthright access only after a production incident or audit finding, rather than through intentional entitlement design.

How It Works in Practice

A practical split starts with classifying entitlements by impact, frequency, and reversibility. If access is low-risk, widely needed, and tightly observable, it can remain birthright with periodic review. If access is privileged, sensitive, or only needed for a discrete task, it should move to JIT with approval, time limits, and automatic revocation. That is especially important for NHIs, where long-lived access often outlives the original business need and becomes invisible.

Security teams should map each entitlement to the smallest workable access pattern:

• Keep birthright for low-impact tools such as standard collaboration, read-only reporting, or routine ticketing systems.

• Use JIT for production changes, secret retrieval, customer data access, admin consoles, and infrastructure controls.

• Require contextual checks for JIT requests, such as ticket linkage, environment, time window, and peer or manager approval.

• Prefer short-lived credentials over standing secrets, especially for service accounts, API keys, and automation identities.

• Review access paths after application changes, because a formerly harmless entitlement can become high-risk when permissions expand.

NHIMG research shows the scale of the problem: the 2024 Non-Human Identity Security Report found that only 19.6% of security professionals are strongly confident in their organisation’s ability to securely manage non-human workload identities. That confidence gap is one reason time-bound access is gaining traction. Current guidance suggests pairing JIT with policy-based enforcement and strong lifecycle controls, rather than relying on manual approvals alone. Where teams use identity governance tooling, the key is to encode entitlement classes and re-evaluate them at change time, not just during annual access reviews. These controls tend to break down in fast-moving hybrid environments because entitlement sprawl makes ownership, usage, and risk harder to keep current.

Common Variations and Edge Cases

Tighter JIT controls often increase operational overhead, so teams have to balance security gains against user friction and admin burden. Not every entitlement should be forced into JIT, and current guidance is not fully uniform on the threshold. For low-risk access with frequent daily use, birthright plus monitoring can be more efficient than repeated approval workflows. The key is to avoid defaulting to permanence just because an entitlement is convenient.

Edge cases usually appear when access is shared, delegated, or embedded inside automation. For example, a reporting entitlement may look harmless until it exposes export functions or sensitive fields. A service account may appear low risk until it can invoke APIs that reach secrets or infrastructure controls. NHI Management Group’s Azure Key Vault privilege escalation exposure and JetBrains GitHub plugin token exposure both illustrate how seemingly ordinary access paths can become high-impact when secrets or tokens are reachable.

Best practice is evolving toward continuous entitlement validation: if the system, data classification, or downstream privilege changes, the birthright/JIT decision should be revisited immediately. In other words, the split should follow the current blast radius, not the historical job title or app category.

Related resources from NHI Mgmt Group

• How should teams decide whether CIAM belongs in the same IAM programme as workforce access?
• How do security teams decide which legacy systems to retire first?
• Why do annual cybersecurity reports matter for IAM teams?
• How should security teams prioritise data security investment across IAM and governance programmes?