Rotate Your Credentials. Rotate Them Where, Exactly?

When a breach hits, the advice arrives before the facts do. Rotate your credentials. You'll read it in the incident writeup, hear it from the vendor, see it in every checklist. It's correct. It's also the most quietly demanding sentence in security, and almost nobody says the quiet part, which is: rotate them where?

Look at what happened to Cisco this spring, because it makes the point better than any hypothetical.

In March 2026, attackers poisoned Trivy, an open-source vulnerability scanner that runs inside thousands of CI/CD pipelines. [Palo Alto Networks] They didn't start at Cisco. They started upstream, by getting into a service account at Aqua Security, the company that makes Trivy, and using it to push a malicious version of the tool to nearly every version tag it had. [Safestate] That poisoned scanner ran silently inside build pipelines, producing normal-looking output while it harvested environment variables, cloud tokens, SSH keys, and AWS credentials in the background. [Safestate] The stolen credentials then got used to walk into Cisco's own build and development environment, clone more than 300 repositories, and reach into a handful of Cisco's AWS accounts. [Tech Newsday; BleepingComputer]

Cisco's response was the textbook one. Isolate the affected systems, reimage the machines, and perform wide-scale credential rotation. [BleepingComputer] That is exactly what you're supposed to do, executed by one of the largest networking companies on earth with a full incident response apparatus.

Now sit with the detail that should stop you cold. Aqua Security, the security vendor at the origin of all this, discovered its own breach and rotated credentials too. The rotation wasn't complete. The attackers kept access to credentials that were missed. [Palo Alto Networks]

A security company, rotating its own credentials, in the middle of an active incident, missed some. Not through negligence. Through the plain difficulty of the task. Because "rotate the credentials" assumes you know, precisely and completely, where every one of them lives and what would notice if it changed. And almost nobody does.

So let's actually walk through what "rotate it" means when you sit down to do it. Take one credential, say an AWS access key that a stealer just grabbed. You go to disable it. Here's what you're really deciding.

What authenticates with this key that isn't a person? The backup job that runs at 2 a.m. The deployment script nobody's touched since the person who wrote it left. The monitoring agent that pulls metrics. The third-party service you wired up eighteen months ago and forgot. Every one of those is holding this credential, and every one of them breaks the moment you rotate it, silently, at whatever hour it next tries to run. You won't get an alert that says "your backup stopped." You'll find out weeks later when you need the backup.

Where is this key actually stored? In the CI/CD environment variables, sure. But also maybe in a config file on a server, in a secrets manager, hardcoded in a container image, pasted into a runbook, sitting in someone's local environment. Rotating the key in one place and not the others doesn't fix your exposure. It just breaks the things that used the old copy while leaving the copies you forgot about fully valid.

Who else has a copy you never authorized? The whole reason this is a breach is that an attacker has it. Rotating removes their access only if you rotate every instance before they use one you missed. Miss one, as Aqua did, and you've done a lot of disruptive work and the intruder is still inside.

None of this is exotic. This is a Tuesday. And for the person reading this who runs security alone, at a company with no secrets manager and no inventory of service accounts, this isn't a fifteen-minute task. It's a discovery project you have never done, being attempted for the first time under the worst possible conditions, during an active compromise, against a clock.

Here's the part I actually want you to take away, because it's bigger than credentials.

If you cannot rotate a credential without guessing what will break, the guessing is the finding. Not the breach. The breach was just the thing that made you look. What you found when you looked is that you don't have a map of your own dependencies. You don't know what authenticates to what. You don't know where your secrets live or how many copies exist or which machine will fall over at 2 a.m. if you touch the wrong one.

That's not a credential problem. That's an inventory problem, and it was there long before the breach. It will be there after. Rotating the exposed key treats the symptom of this one incident. The disease is that you're operating a system whose internal wiring you can't see.

So the honest version of the advice isn't "rotate your compromised credentials." It's this. Rotate them, yes, right now, do that. But if the act of rotating just taught you that you don't know where they all are, stop treating that as a footnote to the incident. That is the incident. The next breach, and there's always a next breach, will land on the same blind spot. You can rotate credentials forever and never fix the thing that makes rotation a guessing game.

The distance between "rotate it" and "I can rotate it, cleanly, and know I got all of it" is the entire distance between owning a pile of security tools and actually being secure. Cisco, with everything it has, is still working through that distance. Aqua, a security company, didn't clear it on the first pass.

You are not going to clear it in a panic at 2 a.m. either. So build the map now, while nothing's on fire. Write down what authenticates to what. Find where your secrets live. Know, before you're forced to know, where "there" is.

Because "rotate your credentials" was never the hard part. "Where" was the hard part the whole time. Everyone just forgot to say so.