Treat them as non-human identities with explicit ownership, least privilege, and revocation procedures. The account should exist only for the workflow that needs it, and the SSH key should be rotated when the pipeline changes or the role ends. That reduces the chance that build automation becomes a standing access path into release systems.
Why SSH-backed service accounts need governance, not just key storage
SSH-backed service accounts are easy to treat as a plumbing detail, but in CI/CD they often act as durable access paths into release systems, deployment hosts, and sometimes production-adjacent infrastructure. Governance matters because the key pair is only one part of the control surface, the actual risk comes from who owns the account, what it can reach, how long it lives, and whether there is a clean way to revoke it when the workflow changes.
For teams that want a deeper operating model, a good baseline is to treat the service account as a named non-human identity with a defined purpose, a defined environment boundary, and a defined shutdown path. That framing makes it much easier to distinguish a legitimate automation credential from an orphaned access path that still works long after the pipeline, repo, or deployment process has changed.
Governance also has to account for the fact that CI/CD credentials are often shared across tooling, repositories, runners, and deployment steps. When that happens, a single SSH key can quietly become cross-system access rather than workflow-specific access. The strongest control is not “store the key securely,” it is “make the access narrowly usable, observable, and disposable.”
How to scope ownership, privilege, and lifecycle
Start with explicit ownership. Every SSH-backed service account should have a named business or platform owner, a technical custodian, and a documented workflow that justifies its existence. If the account cannot be tied to one automation path, the default assumption should be that it is broader than necessary.
Next, scope privilege to the workflow, not to the team. The account should authenticate only where the pipeline needs it, and only for the system or command set required for that job. A release job that needs to copy artifacts should not also be able to administer the host, and a build job should not inherit access to long-lived deployment targets just because they are in the same environment.
Lifecycle controls are just as important as authorization. SSH keys should be rotated when the pipeline changes, when the workflow is retired, when the service owner changes, and when there is any sign that the key may have been copied into a broader automation path. SSH Key and SSH Certificate Management Guide is a useful reference for key sprawl, orphaned keys, and rotation discipline, while Guide to NHI Rotation Challenges covers why rotation becomes harder at scale if dependency mapping is weak.
What good governance looks like in CI/CD environments
Good governance makes the access path easy to explain and hard to misuse. In practice that means the account is dedicated to a single workflow, the key is stored and distributed through a controlled process, and the account is removed or disabled when the workflow no longer needs it. If the key survives the workflow, the workflow has not really been governed.
Teams should also prefer bounded alternatives where they exist. If a pipeline can use short-lived or delegated credentials, that is usually better than letting an SSH key become a standing credential. Even when SSH remains necessary, consider whether certificates, jump hosts, or tighter host-level restrictions can reduce the blast radius of the account. NHIMG’s Service Account Security Guide is a useful companion here because it ties ownership, least privilege, and governance into one operating model.
Where CI/CD and deployment systems are involved, governance should include periodic access review, key inventory, and a clear break-glass exception process. CI/CD pipeline exploitation case study shows why pipeline credentials must be governed as access paths, not as incidental config: once an automation identity can reach a release system, it can become a production path even if no human ever intended that outcome.
Risk and Threat Considerations
SSH-backed service accounts in CI/CD are attractive to attackers because they often combine persistence, privilege, and low visibility. If the key is reused, left unrotated, or shared across workflows, a compromise in one pipeline step can become durable access to deployment targets or release infrastructure.
Failure mechanism: Attackers exploit standing SSH access by stealing the key, copying it from build artifacts or runner storage, or abusing a service account that was never revoked after the workflow changed. Once that key is valid beyond the intended job, the account functions as a persistent access path rather than a temporary automation credential.
Impact: The result can be unauthorized code deployment, release tampering, lateral movement into adjacent systems, and delayed detection because the activity may look like normal automation. In high-friction environments, a single leaked key can outlive the pipeline that created it and keep working long after the original control owner has lost track of it.
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 surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | SSH-backed service accounts need revocation when workflows end. |
| NHI-05 — Overprivileged NHI | CI/CD service accounts should only hold the access needed for one workflow. | |
| NHI-07 — Long-Lived Secrets | SSH keys in pipelines become risky when they remain valid beyond the job. | |
| Recommendation — Revoke SSH-backed automation access as soon as the workflow or owner changes. Restrict each SSH-backed service account to the minimum deployment scope it needs. Rotate SSH keys on pipeline change and replace static credentials with shorter-lived access where possible. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH keys are authenticators that need lifecycle control and rotation. |
| AC-6 — Least Privilege | CI/CD service accounts should have narrowly scoped access. | |
| AU-2 — Event Logging | Pipeline-backed SSH access needs traceability for review and incident response. | |
| Recommendation — Manage SSH keys with defined issuance, rotation, and revocation procedures. Limit each CI/CD service account to the minimum system and command access required. Log service account use so access can be reviewed and investigated. | ||
| CIS Controls v8 | 5 — Account Management | Service accounts in pipelines require ownership, review, and removal processes. |
| 6 — Access Control Management | SSH-backed automation access must be limited to approved use cases. | |
| 8 — Audit Log Management | Governance is stronger when pipeline SSH access is logged and reviewable. | |
| Recommendation — Inventory, review, and remove CI/CD service accounts that no longer have a valid purpose. Apply least privilege and revoke unnecessary SSH access promptly. Retain logs that show when automation identities used SSH access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SSH service accounts are access paths that need policy and governance. |
| Recommendation — Define and enforce access rules for pipeline SSH service accounts. | ||
Practitioner Guidance
What to prioritise: Inventory every SSH-backed service account used by CI/CD and verify that each one has a named owner, a single workflow purpose, and a documented revocation path. If you cannot answer those three questions quickly, the account is already too loose.
Decision rule: If an SSH key can authenticate outside the exact job that needs it, treat that as a standing access path and reduce scope before you worry about convenience. If rotation would break the pipeline, that is a sign the pipeline design is too dependent on the credential, not that the credential should be kept indefinitely.
What good looks like: The account exists only for the job that uses it, the key is rotated on workflow change or retirement, and a disabled or expired credential cleanly stops access without manual hunting. The best signal is not “the key is stored safely,” but “the key cannot remain useful after the workflow that justified it has ended.”
Practitioner takeaway: Govern SSH-backed service accounts as disposable automation identities with explicit ownership and revocation, otherwise CI/CD convenience quietly turns into a long-lived access route.
Related resources from NHI Mgmt Group
- How should security teams govern Active Directory service accounts?
- How should security teams replace static credentials in CI/CD pipelines and service accounts?
- How should security teams govern non-human identities alongside human accounts?
- How should security teams govern credentials used by CI/CD pipelines?