Topic starter
06/11/2026 6:36 pm
TL;DR: GitGuardian’s event briefing for the ONE-ISAC Annual Summit 2026 says energy firms are carrying more API keys, tokens and service accounts across IT and OT, often with no owner or rotation. Secrets sprawl and weak NHI governance turn routine integration into persistent exposure.
Editorial analysis by NHI Mgmt Group, based on content published by GitGuardian: “Securing the Energy Sector's Machine Identities”.
Key questions
Q: What problem does ownership attribution solve for service accounts and API keys?
A: It closes the gap between exposure detection and accountable remediation.
Q: Why do leaked secrets remain dangerous after they are detected?
A: They remain dangerous because discovery does not automatically invalidate authentication.
Practitioner guidance
- Inventory machine identities across IT and OT Build a shared register for service accounts, API keys, tokens and certificates, including owner, purpose, environment and expiry state.
- Link secret detection to revocation Treat every exposed credential as active until its access has been confirmed removed, and route findings into a revocation workflow rather than a ticket queue.
- Remove hardcoded credentials from delivery paths Scan source repositories, scripts and CI/CD pipelines for embedded secrets and replace them with governed retrieval at runtime.
Bottom line: Energy-sector integrations now create machine identities faster than many programmes can inventory and govern them.
What to expect at the briefing
GitGuardian's full event briefing covers the operational detail this post intentionally leaves for the source:
- On-site discussion of how energy teams detect leaked secrets in hybrid IT and OT environments
- Summit context on how peers are approaching NHI governance across upstream, midstream and downstream operations
- Practical talking points on ownership, rotation and offboarding for service accounts and API keys
- Direct conversations with the GitGuardian team at the ONE-ISAC Annual Summit in The Woodlands
👉 Register for GitGuardian's event briefing at the ONE-ISAC Annual Summit on machine identities →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:41 pm
Machine identity governance fails when organisations treat credentials as plumbing rather than as governed identities. API keys, tokens and service accounts now sit on the same risk surface as human accounts when they can reach production systems, yet many programmes still manage them as implementation leftovers. That creates blind spots in ownership, review and revocation. Energy operators should treat the machine identity estate as a first-class governance domain, not a back-office secret store.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
- 61% of organisations still define privileged users as humans only, overlooking the role of non-human identities in privileged access, according to KPMG.
A question worth separating out:
Q: What is the difference between service accounts and API keys in non-human identity management?
A: Service accounts and API keys both represent non-human access, but they serve different purposes. A service account is an identity that can be granted permissions and governed like any other account. An API key is usually a credential that authenticates a system or application call. Both need inventory, rotation, scope limits, and revocation controls to reduce exposure.
👉 Read our full editorial: Machine identities and secrets sprawl in energy operations