How do I know if GitHub NHI controls are actually working?

Why This Matters for Security Teams

A GitHub NHI control is only real if it changes exposure, not just documentation. That means inventory completeness, ownership, secret expiry, scope review, and offboarding discipline all have to work together. The operational risk is well documented: NHI sprawl, dormant tokens, and over-privileged integrations are common failure modes, and the Ultimate Guide to NHIs shows how often organisations still lack full visibility into service accounts and secrets. NIST also frames this as a governance and continuous-monitoring problem, not a one-time setup task, in the NIST Cybersecurity Framework 2.0.

For GitHub in particular, the question is whether controls catch the things attackers actually use: leaked PATs, stale app installations, orphaned bots, and CI/CD tokens that survive long after the workflow changed. Research from Top 10 NHI Issues and incident analysis in the Reviewdog GitHub Action supply chain attack show that exposure often persists because teams treat GitHub permissions as static configuration rather than an active identity surface. In practice, many security teams discover the control failed only after a secret has already been reused outside the intended workflow.

How It Works in Practice

The strongest way to verify GitHub NHI controls is to test the full identity lifecycle, not a single setting. Start with a live inventory of every GitHub App, service account, bot, token, and deployment credential. Then confirm each identity has a named owner, an approved purpose, a scope that matches that purpose, and a documented expiry or rotation schedule. That is the difference between a control that exists on paper and one that actually reduces risk.

Operationally, the checks should map to what attackers exploit in real environments: long-lived secrets in repos, broad app scopes, stale PATs, and integrations that were never removed. The 52 NHI Breaches Analysis and the NIST Cybersecurity Framework 2.0 both support a continuous assurance model: detect, review, remediate, and re-test.

• Verify no token is active without an owner and a business purpose.
• Check whether expired credentials are truly unusable, not just marked expired in a ticket.
• Review GitHub App permissions against actual runtime usage, not request history.
• Test offboarding by disabling a token and confirming the integration fails safely.
• Sample CI/CD jobs to confirm secrets are injected JIT and not stored long term.

Good controls also need evidence. A mature program can show rotation logs, scope diffs, approval records, and access-review outcomes that line up with actual GitHub state. These controls tend to break down when teams rely on manual reviews across large numbers of repos and automation accounts because stale access accumulates faster than humans can validate it.

Common Variations and Edge Cases

Tighter GitHub NHI control often increases operational overhead, so organisations have to balance speed against assurance. That tradeoff is real, especially in fast-moving CI/CD environments where many identities are short-lived but still powerful.

Best practice is evolving for edge cases such as shared automation accounts, marketplace apps, and org-wide bots. There is no universal standard for every GitHub integration pattern yet, but current guidance suggests treating each one as a separate workload identity with its own scope, owner, and rotation path. That aligns with NHIMG’s broader NHI governance guidance in the Ultimate Guide to NHIs and with incident patterns seen in the Cisco DevHub NHI breach, where exposed or poorly governed non-human access becomes a path to broader compromise.

Two edge cases deserve special attention. First, some GitHub tokens are intentionally shared across workflows, but shared access is a risk amplifier and should be treated as an exception requiring compensating controls. Second, some secrets are “valid” but operationally dead, meaning they still authenticate even though no one uses them. Those are still failures because dormant access is exactly what persistence looks like in NHI governance. In practice, the control is not working if an attacker can still find a forgotten credential and use it without immediate detection.

Related resources from NHI Mgmt Group

• How do organisations know whether NHI controls are actually working?
• How do you know if machine identity automation is actually working?
• How do security teams know if secret rotation is actually working?
• When does secrets rotation actually reduce NHI risk?