Notifications
Clear all
Topic starter
25/05/2026 8:40 pm
TL;DR: Most enterprises can govern cloud identities, but on-prem and self-hosted systems still sit outside that control plane because the obvious fix requires opening the network perimeter, according to Unosecur. That leaves access review, logging, and auditability incomplete where long-lived permissions and legacy systems create the most persistent NHI risk.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 5.7% of organisations have full visibility into their service accounts.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: How should teams extend identity governance into on-prem systems without opening inbound access?
A: Use an agent-based collection pattern that runs inside the customer boundary, gathers identity evidence locally, and sends only metadata outward.
Q: What is the difference between governing cloud identities and governing private legacy systems?
A: Cloud identities are usually easier to discover and review because the control plane is already reachable.
Q: When does visibility tooling create more risk than it reduces?
A: Visibility tooling creates more risk when it requires inbound access, shared credentials, or broad firewall changes just to collect data.
Practitioner guidance
- Implement perimeter-safe identity collection Deploy collectors that run inside the customer environment, use local access only, and transmit identity metadata outward without requiring open inbound ports.
- Map private systems into the identity estate Include self-hosted GitHub, private Jira, private Okta, and internal applications in the same access review and logging process used for cloud identities.
- Validate private transport controls Require mutual TLS or private connectivity for any identity telemetry leaving regulated environments, and document where public internet transit is prohibited.
Teams should expect identity programmes to expand inward, not just outward, and they will need collection patterns that survive audits as well as outages?
👉 Read Unosecur's analysis of governing identity data in on-prem and self-hosted systems →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
Mr NHI reacted
25/05/2026 8:40 pm
The governance gap is architectural, not procedural. Most enterprises do not lack policy language for on-prem systems. They lack a collection model that respects private network boundaries while still producing identity evidence. That means the control failure sits in the plumbing of visibility, not in the intent of the programme. Teams should stop treating this as an edge case and design for it as a core NHI governance requirement.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Why do on-prem systems remain a blind spot in many NHI programmes?
A: On-prem systems remain a blind spot because many identity programmes were built around cloud connectivity assumptions. Once a system is private, the easiest discovery methods often collide with security policy, so teams postpone coverage. The result is a growing pool of unreviewed permissions, untracked accounts, and weak audit evidence.
👉 Read our full editorial: On-prem identity governance still breaks where cloud tools stop
Mr NHI reacted
