The deliberate use of multiple package publishing identities to continue a campaign after detection or takedown. This tactic weakens response if defenders focus on one account rather than the shared infrastructure, naming patterns, and credential relationships behind the activity.
Expanded Definition
Publisher account rotation is a post-detection persistence tactic in software supply chain abuse, where the actor shifts from one publishing identity to another to preserve release capability after a takedown. The important distinction is that the account is only the visible layer; the real continuity often lives in shared infrastructure, reusable build pipelines, naming conventions, signing material, and credential relationships. In NHI governance, this makes publisher identity closer to an operational control plane than a simple login. Guidance varies across vendors on whether to treat it as account rotation, campaign rotation, or identity reconstitution, but the security problem is consistent: the adversary is maintaining publishing access while changing the outward-facing persona. That means defenders need to correlate package metadata, token reuse, CI/CD provenance, and repository ownership, not just deactivate a single account. The concept aligns closely with the control intent in the OWASP Non-Human Identity Top 10, especially where secret handling and identity lifecycle failures enable repeated abuse. The most common misapplication is treating publisher account rotation as a one-off compromise, which occurs when response teams revoke only the named account and ignore the shared publishing substrate.
Examples and Use Cases
Implementing detection and response for this tactic often introduces a tradeoff between aggressive takedown speed and the risk of disrupting legitimate publishing workflows, so organisations must weigh containment against service continuity.
- A malicious package maintainer loses access to a compromised npm publisher account, then resumes uploads from a new account that reuses the same CI token pattern and package naming scheme.
- A malware campaign moves between multiple GitHub and registry identities after each suspension, while the same build server and signing key material remain unchanged. This is the kind of lifecycle weakness discussed in the NHI Lifecycle Management Guide.
- Defenders link new publisher accounts to the same automation host by correlating commit timing, release artifacts, and secret access paths, a pattern that mirrors the broader secret concentration risks covered in the Guide to the Secret Sprawl Challenge.
- A supply chain team validates release provenance against package signing and repository controls, using the assurance concepts in NIST SP 800-53 Rev 5 Security and Privacy Controls to reduce dependence on a single publisher identity.
- An incident responder maps multiple publisher handles to one campaign when the same support email, API token exposure pattern, and upload cadence recur across accounts.
Why It Matters in NHI Security
Publisher account rotation matters because response teams that only chase visible accounts usually miss the durable assets that make the campaign repeatable. NHI security fails here when publishers are treated as disposable personas rather than governed identities with lifecycle controls, secret hygiene, and provenance checks. NHIMG research shows that 2024 Non-Human Identity Security Report found 88.5% of organisations say their non-human IAM practices lag behind or only match human IAM, which helps explain why publisher identity abuse can persist across takedowns. This is compounded when secrets are duplicated, overused, or stored in places that make rapid account switching easy, a theme reinforced by the Guide to NHI Rotation Challenges and the 2025 State of NHIs and Secrets in Cybersecurity findings on duplicated secrets and exposed tokens. The operational lesson is that publishing identity, signing authority, and access tokens must be managed as linked NHIs, not isolated incidents. Organisations typically encounter the full impact only after repeated package abuse or a public takedown fails, at which point publisher account rotation becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Publisher rotation often depends on weak secret handling and reused access paths. |
| NIST CSF 2.0 | PR.AA | Identity proofing and access management govern who can publish and re-publish software. |
| NIST SP 800-63 | Assurance concepts inform how strongly a publisher identity should be authenticated. | |
| NIST Zero Trust (SP 800-207) | SP 5 | Zero trust requires continuous verification of identity, context, and authorization for each publish action. |
| NIST SP 800-53 Rev 5 | SA-12 | Supply chain protection controls cover provenance, source integrity, and trustworthy release processes. |
Require higher assurance for publishing workflows and prevent low-trust identities from gaining release authority.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
