Triage of 4,200 Discovered Nonhuman Identities

Sequence by risk reduced per unit of effort, not by count.

Ordering criteria (apply in this order):

1. Exposure - is the credential reachable by an attacker today (public repo, internet-facing host, shared wiki)? Git-history API keys rank first because they are already leaked.
2. Blast radius - shared or high-privilege credentials (domain admin, DBA, cloud root) outrank single-purpose accounts.
3. Ownership - an account with a named owner can be onboarded and rotated safely; one without an owner cannot, because no one can confirm the app still needs it or fix a broken consumer.
4. Rotation feasibility - accounts with a known, testable consumer path go before vendor-binary accounts.

Practical tranches:

• Weeks 1-2: all 600 exposed keys - onboard, rotate, and purge Git history. No dependency on ownership because the key is already compromised.
• Weeks 2-8: 1,100 AD service accounts in owner-confirmed batches of ~50, with reconciliation (confirm the account is still used) before rotation.
• Weeks 6-12: 2,300 SSH keys, prioritized by host criticality and key age.
• Deferred: the 200 scheduled-task accounts and 300 vendor-binary accounts, until ownership is established and a credential-injection workaround exists.

Use the remaining four weeks of tool licence for a second discovery pass, not for onboarding. Re-scanning proves nothing new was created during the project and gives you the 'after' baseline the board will ask for.

These accounts will fail at the worst possible moment. The binary authenticates with an embedded password; when the vault rotates it, the binary keeps presenting the old value. Behaviour depends on the lockout policy: with a low threshold the service account locks and settlement stops; with a long password history the binary may keep working until the old password is purged, which hides the fault for weeks and then fails after the next drift. Either way the rotation is not actually effective - the real secret remains the one in the binary.

Correct treatment:

• Classify them as an exception with a named owner and an expiry date, not as 'in scope, rotate anyway'.
• Compensating controls while unresolved: restrict the account's logon rights to the specific batch servers, deny interactive and remote logon, alert on authentication from any other source, and monitor for the account appearing in new locations.
• Replace the credential dependency: vendor patch, wrapper that retrieves the credential at runtime, or migration of the job to a scheduler that injects the secret from the vault at launch. Only then onboard and rotate.
• Because the binary password is effectively a plaintext secret, it must be handled as a leaked credential - treat the file as sensitive, restrict read access, and record it in the risk register.

Rotating them 'for compliance' produces a green dashboard and an unchanged risk, plus a live outage risk. Auditors accept a documented exception with compensating controls far more readily than an unverified rotation.

You do not need a rotation engine to reduce SSH key risk materially; you need inventory, ownership, and removal of the worst keys. A defensible quarter-one programme:

1. Map key to login path. For each key pair, record the private-key location, the authorized_keys entry it satisfies, the source host, and the human or service that owns it. Keys with no matching private key, or whose owner has left, are deleted immediately - that is pure risk removal with no availability impact.
2. Rank by exposure. Internet-reachable sshd, keys without a passphrase, keys older than 365 days, and keys in authorized_keys with from= unset and no command restriction go first.
3. Constrain before rotating. In authorized_keys, add from=, command=, no-port-forwarding, no-agent-forwarding, no-pty where the use case allows. This limits what a stolen key can do even before replacement, and it is faster than a full re-key programme.
4. Re-key in place, per host group. Generate key pairs on the workload (or issue short-lived certificates via a CA), install the new public key alongside the old, verify logins, then remove the old entry and the old private key. Doing it per host group keeps blast radius to one group.
5. Long-term direction: SSH certificates with a short TTL issued through the vault removes the standing-key problem entirely, but it is a project, not a quarter-one deliverable.

Report progress as keys deleted plus keys constrained plus keys re-keyed - three numbers, not one percentage.