Monday's move was simple on paper: rotate the oldest secret with production reach and watch what happens. Talk to enough practitioners who've actually run it, though, and the story sounds the same every time.
Someone was up against a deadline. A launch that couldn't slip, or a demo that had to work by end of day. The proper way to provision a credential meant filing a request and waiting on a secrets-manager entry, lead time the deadline simply didn't have. So they generated a key, dropped it straight into a script or a config, and told themselves they'd circle back and do it properly once things calmed down.
Things never really calm down. The circle-back doesn't happen, not out of negligence, just because there's always a next deadline crowding out the last one. The credential sits there quietly doing its job. It's invisible on any architecture diagram because nobody ever went back to draw it in.
Then, months or years later, somebody else finds it. They're building something new, they need a working credential for the same service, and there's one sitting right there in a shared doc or an old script, clearly functional. So they copy it. They don't loop in the original owner, because they have no idea there is one to loop in.
That's the moment rotation exposes. Pull that credential to rotate it, and the first system updates cleanly. A second system, one nobody had connected to the first, quietly breaks a few minutes later. Two teams who have never spoken to each other turn out to be standing on the same key.
Nobody broke policy in that story. No policy usually covers reusing a working credential you happened to find lying around. That's exactly what makes it worth naming.
Call it shadow dependency drift: a credential built for one purpose, discovered later, and quietly repurposed for a second one that nobody wrote down.
Unlike shadow IT, nobody here is hiding anything on purpose. Each person solved a real problem quickly with what was already sitting in front of them, and the drift built up silently because every individual reuse looked completely reasonable on its own terms.
That's what makes it dangerous. It fails the exact test an access review is built to run. Access reviews ask who has permission to what, and answer that question well. What they don't ask is who's actually using a credential nobody granted them directly, so a key can be perfectly scoped, perfectly logged in every audit, and still be silently load-bearing for a system three teams away.
Get burned by this once, and the instinct is to lock everything down: fewer shared credential docs, more friction on every request that touches a secret. That instinct is understandable, and it also misses the point. Friction on the front end tends to push people right back toward the shortcut that caused the problem, because a copied credential is always going to be faster than a proper request when the deadline is real. A tighter rotation interval doesn't touch any of that. What actually helps is a way to surface reuse before rotation forces the discovery on you, and that has far less to do with policy than with visibility into what quietly borrows what.
Treating a stale secret as too tangled to touch doesn't make it any safer. It makes it more valuable to whoever finds it first. The more dependencies wrap around a credential, the less anyone on the team actually understands what it touches, and that gap is exactly what an attacker goes looking for. Every month it sits unrotated, it stays available, unmonitored, and poorly understood by the people supposedly defending it, while an attacker doesn't have to work nearly as hard to find a path your own team was too nervous to walk.
Programs that only rotate on a calendar tend to find dependencies like this the hard way, mid-incident, when an update breaks something nobody saw coming. Programs that treat every rotation as a planned discovery exercise, with someone actually watching for this kind of surprise, catch it on an ordinary Tuesday afternoon instead of during an outage bridge at two in the morning.
Applying this is more a habit shift than a tooling one. Before rotating any credential with real reach, spend fifteen minutes asking a wider question than what officially depends on this. Look at shared docs and old scripts, and check whether the credential turns up anywhere outside its original owner's system.
Run that exercise once and turn up a surprise, and a team stops trusting its own architecture diagrams by default. Documentation starts to feel like a hypothesis worth testing rather than a record worth trusting. That shift is what changes how the next rotation actually gets handled, well before the next incident tries to teach the same lesson the hard way.