You inherit a system with several hundred long-lived credentials spread across services, pipelines and machine accounts. How do you decide which ones to fix first, and what does "fix" mean for each?

## Why ranking is the actual skill With hundreds of credentials, everything cannot be fixed, and the naive orderings are wrong. Working alphabetically, or by whichever team responds, or by whatever a scanner surfaced first, all ignore that the credentials differ in expected cost by orders of magnitude. The goal is to reduce expected loss per unit of engineering effort, so you need a model of loss. ## The three primary axes **Exposure — how many principals and stores can reach it.** Count copies honestly: how many humans can read it, how many pipelines reference it, how many machines hold it on disk, whether it appears in a manifest that a wide group can view, whether it ever passed through a log. The extreme point is a credential embedded in anything distributed to users — a browser bundle, a mobile package, a customer-installed agent — which should be scored as already public, since extraction is a one-time cost the attacker pays and can share. **Privilege — what it authorizes.** The right question is what the *holder* can do, not what the service currently does. A credential with administrative rights that is used only for one read is scored on the rights, because compromise grants the rights. Watch for credentials whose privilege has drifted upward over years of "just add this permission to unblock the release". **Sensitivity — what it reaches.** Regulated personal data, financial movement, and anything that can alter the deployment or build path score highest. Credentials that reach the CI/CD system or a package registry belong near the top of every list, because they let an attacker change what runs everywhere and reach every other credential — a credential that can obtain other credentials inherits the union of their privilege. ## The two multipliers people miss **Shared credentials destroy attribution and make revocation an outage.** When forty services present the same value, authentication logs cannot tell you which one is misbehaving, an anomaly cannot be traced to an owner, and revoking to contain a suspected leak breaks all forty at once. The predictable consequence under pressure is that nobody revokes. One credential per principal is therefore not tidiness; it is what makes both detection and containment possible, and it is usually the highest-leverage structural change available. **Rotation cost is a risk multiplier.** A credential that takes a week of coordination to change is one you will not change when it is exposed. Cost-to-rotate belongs in the score directly, and it explains the sequencing below: capability precedes cadence. ## Sequencing the work 1. **Make rotation cheap and rehearsed.** Overlapping validity of two generations, generation identifiers recorded in authentication logs so retirement is evidence-based, consumers that re-read rather than freeze at startup, and an automated re-issue path. Until this exists, every other finding is a report you cannot act on. 2. **Split shared credentials into one per principal.** This restores attribution and makes revocation surgical, and it converts "we cannot revoke" into "we can revoke one thing". 3. **Narrow scope.** Reduce each credential to the operations and resources its holder genuinely needs, ideally constrained to specific resources rather than whole services. Scope does not prevent disclosure; it decides what disclosure costs, and it is durable in a way that alerting is not. 4. **Shorten lifetime, and prefer issuance to storage.** Replacing static values with short-lived credentials obtained via an attested workload identity removes the durable bearer value entirely. It is the structural-separation rung and the only change that eliminates the class rather than bounding it. It also shifts defensive attention to the issuance path, which is a smaller and more monitorable surface. 5. **Turn on detection.** Scanning of repositories, history, pipelines and build artifacts, plus alerting on credential use that deviates from an established pattern — now genuinely useful, because a hit produces a rotation rather than a ticket. ## What "fix" means, case by case - **In a client-distributed artifact:** architectural. Move the privileged operation behind a server-side component; give the client its own per-install or per-user revocable identity. Obfuscation is not on the table. - **Shared static credential across services:** split per consumer, then rotate each independently; if the verifier permits only one secret per identity, create per-consumer identities instead. - **High-privilege pipeline credential:** scope to the specific repositories and artifacts, replace with short-lived issued credentials tied to the pipeline's identity, and constrain which branches or workflows may request it. - **Legacy system with no rotation support:** you cannot fix the credential, so contain it — isolate the network path, restrict which hosts may authenticate, add monitoring for use outside the expected source, and treat that containment as compensating rather than curative. ## What to report upward Executives cannot use a list of hundreds. Report the small number of credentials whose compromise would be materially damaging, the current time-to-revoke for each, and the trend in that number. Time-to-revoke is the honest single metric, because it captures whether the organisation can actually respond, whereas count-of-secrets-found measures how hard the scanner was tuned.