Notifications
Clear all
Topic starter
08/06/2026 4:22 pm
TL;DR: Real-time approval, denial, and locking of access requests can help reduce standing privilege and enforce resource limits, according to Teleport. The governance issue is bigger than speed: JIT policy only works when identity, approval, and audit controls are aligned to prevent access sprawl.
NHIMG editorial — based on content published by Teleport: Immediate, Automated, Compliant Access Enforcement with Teleport JIT Watcher
Questions worth separating out
Q: How should security teams automate JIT access without creating new governance blind spots?
A: Security teams should automate only the repeatable decision layer, then keep exception handling and policy ownership under human control.
Q: Why do standing privileges keep reappearing in environments that already use JIT access?
A: Standing privilege reappears when policy is not expressed as a state change.
Q: What breaks when access reviews are the main control for JIT governance?
A: Access reviews break down when access changes faster than review cycles can observe.
Practitioner guidance
- Define explicit JIT state rules Map the access states that should auto-approve, auto-deny, or auto-lock, then test them against production, research, and other mutually exclusive role combinations before rollout.
- Treat the enforcement service as an NHI Assign the watcher its own machine identity, scope its API permissions tightly, and review its access as part of NHI lifecycle governance rather than as an application detail.
- Instrument decision logging for every policy action Record the request, rule matched, and state change for each approval, denial, or lock so auditors can reconstruct why access changed without relying on manual explanation.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- Sample watcher implementation in Go, including the polling and request-handling flow
- Machine ID setup details for authenticating the watcher to Teleport's gRPC API
- The exact resource-count and environment-separation policies used in the proof of concept
- Systemd deployment example for running the watcher as a long-lived service
👉 Read Teleport's blog post on immediate, automated JIT access enforcement →
JIT access watchers: are your controls keeping up with privilege sprawl?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
08/06/2026 5:58 pm
JIT automation does not remove the access sprawl problem, it formalises the policy boundary around it. The article shows that organisations still struggle with standing access, environment overlap, and request hoarding even when they adopt JIT. The watcher reduces manual effort, but the underlying governance question remains whether policy can keep pace with how people actually work. Practitioners should treat automation as enforcement of a design choice, not as proof that the design is complete.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: How should organisations govern the service that enforces JIT policy?
A: Organisations should govern the watcher as a privileged non-human identity with its own scope, logging, and review requirements. If the enforcement service can approve, deny, and lock requests, then its identity and permissions matter as much as the identities it governs. That control should sit inside NHI lifecycle and audit processes.
👉 Read our full editorial: JIT watcher automation narrows access sprawl, but not governance risk
