Dynamic identity should come first when package publishing or CI/CD relies on reusable secrets with broad reach. Rotation still leaves the organisation managing stored credentials and reacting after compromise. Ephemeral identities reduce the number of reusable secrets in circulation and remove the easiest path for worm propagation.
Why dynamic identity beats rotation for package publishing
For package publishing, the decision is not really “rotate less” versus “rotate more”. The real choice is whether the publishing path depends on reusable credentials at all. Dynamic identity changes the trust model by giving the pipeline short-lived, purpose-bound access. Rotation improves hygiene, but it still leaves a stored secret in circulation and a standing path that can be reused if exposed.
That difference matters most when build or release systems can publish repeatedly from the same secret. A rotated key may be fresh, but it is still an enduring bearer of authority. Ephemeral identities, by contrast, shrink the blast radius and remove the easiest persistence mechanism for an attacker who reaches the pipeline, artifact store, or developer workstation.
In practice, the better question is whether package publishing can be designed so the publisher proves who it is at runtime, then receives a narrow publishing grant that expires immediately after use. That model aligns better with modern CI/CD because it reduces secret distribution, secret storage, and the operational burden of tracking every place a publishing credential may have been copied.
Where key rotation still helps, and where it is the wrong primary control
key rotation still has value when you already have long-lived credentials, especially for legacy package registries, third-party tooling, or release flows that cannot yet issue ephemeral access. It is a compensating control, not the strongest design goal. For teams that want a practical bridge, NHIMG’s Ultimate Guide to NHIs, Static vs Dynamic Secrets is useful because it frames why short-lived credentials reduce exposure better than repeated secret replacement.
Rotation becomes less effective as environments scale. The more systems, runners, repositories, and deploy jobs that can touch the same secret, the more places you must coordinate rotation and the harder it is to prove complete removal of the old value. That is why package publishing workflows often fail in the gap between “we rotated it” and “every cached copy is gone”.
Dynamic identity is the stronger option when the publishing action is machine-initiated, repetitive, and bounded by automation. In that case, the control should be built around ephemeral issuance, tight audience restriction, and automatic expiry. NHIMG’s Guide to NHI Rotation Challenges helps show why rotation alone becomes operationally brittle once multiple systems depend on the same publisher secret.
What package-publishing teams should change first
The most important shift is to map every publish path to the minimum access it actually needs. If a job only needs to upload one package to one registry, it should not hold a reusable credential that can reach other environments or administrative APIs. Where possible, issue a fresh identity per run or per release event, then expire it as soon as the publish step completes.
NHI lifecycle management is the practical lens here: provisioning, use, expiry, and offboarding should be part of the publishing flow, not an afterthought. NHIMG’s Guide to the Secret Sprawl Challenge is also directly relevant because package publishing is one of the easiest places for secrets to spread through CI/CD, build logs, and developer tooling.
Cryptographic key management still matters for signing keys, but signing integrity is a different problem from publisher access. Teams should separate “can this artifact be trusted?” from “can this process push it?” and avoid using long-lived publisher credentials as if they were the same control as code or artifact signing keys.
Risk and Threat Considerations
Package publishing secrets are attractive because they often sit at a high-trust point in the software supply chain. If an attacker steals a reusable publishing credential, they may be able to publish malicious packages, replace artifacts, or extend access into broader build and release systems. Dynamic identity reduces that opportunity by limiting how long a credential can be replayed and where it can be used.
Failure mechanism: A long-lived publishing secret is copied into pipelines, caches, logs, or developer environments, then reused after exposure or compromise. Rotation can remove the old value, but it does not prevent the original leakage path or the reuse window that existed before rotation.
Impact: The practical consequences are package tampering, trusted release compromise, and wider supply-chain exposure. At scale, one exposed publisher secret can create repeated compromise opportunities across multiple repositories, registries, or automated release jobs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5, NIST SP 800-57 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Package publishing depends on reusable secrets that can leak from CI/CD paths. |
| NHI-07 — Long-Lived Secrets | The question compares rotation with ephemeral identity for standing credentials. | |
| NHI-05 — Overprivileged NHI | Publishing credentials often carry broader access than one release step needs. | |
| Recommendation — Eliminate reusable publishing secrets and bind release access to short-lived credentials. Prefer ephemeral publishing access over standing secrets that need periodic rotation. Scope publishing identities to the minimum registry and artifact permissions required. | ||
| CIS Controls v8 | CIS-5 — Account Management | Publishing identities need tight lifecycle control and removal when no longer needed. |
| CIS-6 — Access Control Management | Package publishing should be limited to the minimum access needed for the task. | |
| Recommendation — Use automated account lifecycle control for build and release identities. Restrict publish rights to the smallest set of systems and actions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The subject is whether to manage publisher credentials by rotation or replace them with ephemeral identity. |
| IA-9 — Service Identification and Authentication | CI/CD publishing is a machine-to-machine access problem. | |
| AC-6 — Least Privilege | Publishing access should be narrowly bounded to reduce blast radius. | |
| Recommendation — Manage authenticators so publisher credentials are short-lived and tightly controlled. Use service-to-service authentication for publishing instead of shared secrets. Grant only the permissions required to publish a package. | ||
| NIST SP 800-57 | 3 — Key Lifetimes and Cryptoperiods | Rotation and lifetime limits are central to the question’s key-management tradeoff. |
| Recommendation — Set short cryptoperiods and align key lifetime with the release task. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Ephemeral identity for publishing commonly relies on federated, short-lived token exchange. |
| Recommendation — Prefer federated short-lived tokens over stored publishing credentials. | ||
Practitioner Guidance
What to prioritise: Replace reusable publishing secrets first in the workflows that can reach production registries or signed release channels. If a release step can be converted to short-lived, scoped identity, do that before investing further effort in periodic rotation of the old secret model.
What to verify: Confirm that the publishing identity expires automatically, cannot be reused outside the release job, and is bound to the narrowest possible registry, repository, or artifact scope. If any cached token, secret export, or shared runner state survives the job, the control is weaker than it looks.
Practitioner takeaway: Rotation is still useful as a fallback, but for package publishing the better security outcome comes from eliminating standing publisher secrets wherever the workflow can support ephemeral, bounded identity.
Related resources from NHI Mgmt Group
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams protect npm and package publishing workflows from identity compromise?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?