Your CI system has one deploy credential, set up years ago when there was one service to deploy. There are now forty services, forty pipelines, and every one of them still uses that same credential, because splitting it later never made it onto anyone's list of things to fix.
That credential can deploy to production, which for most platforms means it can also read the configuration, secrets and infrastructure state of everything it deploys to. A single leaked token, from any one of forty pipelines, is a compromise of all forty.
This post is about the blast radius a shared deployment credential quietly accumulates. For whoever set it up once and never revisited it.
Why one credential is the default
It is genuinely the fastest path when a company has one or two services. Provisioning a scoped credential per service is extra setup for a benefit that does not exist yet, because there is nothing to scope against, and the natural thing to do when the third and fourth services arrive is to reuse what already works rather than build a new pattern for a problem that has not caused an incident yet.
The credential then survives every subsequent addition by default, because removing it requires a deliberate migration and adding to it requires nothing at all.
What actually accumulates behind it
Every pipeline that references the credential can do whatever the credential can do, regardless of what that specific pipeline was built to deploy. A pipeline for an internal reporting tool, built by whoever needed a dashboard, ends up holding a credential capable of touching your payment processing service, because both pipelines were configured against the same organisation-wide secret.
Compromise of the least important pipeline is compromise of the most important one. An attacker does not need to find a way into your most carefully guarded service. They need to find the pipeline with the weakest review process, the one nobody has looked at since it was written, because it holds exactly the same access as everything else.
Every engineer who can trigger any pipeline can effectively deploy anywhere the credential reaches. Access control at the level of "who can run this specific pipeline" becomes meaningless once every pipeline shares the same underlying authority, because the pipeline boundary was never actually an authorisation boundary, just an organisational convenience.
Rotation becomes an all-or-nothing operation. A single shared credential means rotating it requires touching every pipeline that references it simultaneously, which is disruptive enough that rotation gets deferred, which is precisely the outcome you want to avoid for a credential this powerful.
The scoping that actually matters
Per-service credentials, each authorised only for the specific resources that service deploys to. A pipeline for service A should be unable to touch service B's infrastructure even if someone with access to A's pipeline configuration wanted it to, because the credential itself, not a policy document, prevents it.
Environment-scoped separately from service-scoped. A credential authorised to deploy service A to staging should not also be valid for deploying service A to production, because a compromise of your staging pipeline, generally the less carefully guarded of the two, should not translate directly into production access.
Short-lived, federated credentials where your platform supports them, issued per pipeline run rather than stored as a long-lived secret at all. This removes the rotation problem entirely, because there is nothing sitting in a secrets store waiting to be leaked; the credential exists only for the duration of the run that requested it.
A credential inventory that maps each one to exactly what it can reach. Not a list of secret names, a list of scopes: this credential can deploy to this service, in this environment, and nothing else. If producing that list for your current setup takes more than a few minutes, the scoping has already been lost somewhere along the way.
Migrating without a big-bang rewrite
The realistic path, because rewriting forty pipelines simultaneously is its own risk:
Start with the highest-consequence service, the one whose compromise would matter most, and give it its own scoped credential first, leaving everything else on the shared one temporarily. This immediately removes your most important service from the shared blast radius while the rest of the migration continues at a sustainable pace.
Move new pipelines to scoped credentials from the start, so the shared credential's reach stops growing even before the existing pipelines are migrated off it.
Track which pipelines still reference the shared credential as an explicit, visible list, the same way you would track any other piece of technical debt with a real security cost, rather than letting it become invisible simply because nothing has gone wrong yet.
Check yours
# For your CI platform's secrets or variables, how many pipelines
# reference the same deploy credential?
grep -rln "DEPLOY_TOKEN\|DEPLOY_KEY" .github/workflows/ .gitlab-ci.yml 2>/dev/null | wc -l
# What can that credential actually reach? Check the platform side,
# not just where it is referenced.
If the count from the first command is close to your total number of pipelines, you have one credential doing the work that should belong to many, and the second question, what it can actually reach, is the number that describes your real exposure.
The concession
Full per-service, per-environment credential scoping is genuinely more infrastructure to build and maintain than one shared secret, and for a small number of services run by a small, trusted team, the operational overhead of granular scoping can outweigh the risk it addresses. Not every team needs the complete version immediately.
The migration priority that holds regardless of team size: production access matters more than staging, and your highest-consequence service matters more than the rest, so if full scoping is not immediately achievable, split along those two lines first and treat the remainder as a backlog item with an owner, rather than leaving everything on one credential because the full solution felt too large to start.
The implication
A shared deployment credential means your actual security boundary is not your service architecture, your access control policies, or your pipeline review process. It is whichever pipeline is easiest to compromise, because all of them grant the same access regardless of what they were built to do.
Count how many pipelines reference your deploy credential today. That number, not your org chart or your architecture diagram, is the real description of what a single leaked secret would cost you.
