The safest pattern is to keep the build and publish steps in CI, then require a short-lived human approval step before the release secret is released. That preserves ephemeral runners, reduces dependence on a developer laptop, and keeps the final publish action under manual control. The key is to use temporary credentials only for the release moment, not a standing automation token.
Why this pattern works for CI/CD publishing
The approval should gate the release credential, not the build pipeline itself. That preserves the automation benefits of CI while making the final publish action a deliberate human decision. The practical goal is to keep the release path short-lived, auditable, and separated from the broader build environment, so an approval does not become a standing secret or a reusable bypass.
In practice, this means the pipeline can prepare artifacts, validate them, and stage them, but the publish privilege is only activated after a reviewer approves the release window. That preserves ephemeral runners, avoids dependency on a developer laptop or shared workstation, and keeps the human step focused on whether this specific release should go live now.
When teams try to preserve MFA by moving publishing back to an operator workstation, they often reintroduce the very risk CI was meant to remove: persistent local credentials, weaker traceability, and a broader blast radius if the workstation is compromised. A safer design uses temporary credentials for the release moment only, then revokes or expires them immediately after publishing.
What the approval should and should not do
The approval step should authorize a narrow action, not unlock a general-purpose automation identity. A reviewer should be approving a bounded release event, with scope limited to the target environment, artifact, and time window. If the approval grants more than publish rights, such as broad repo, infrastructure, or production admin access, the control has drifted from release governance into privilege escalation.
- Keep build, test, and artifact creation fully automated in CI.
- Require human approval only at the release gate where the publish secret or token is minted.
- Use short-lived credentials with explicit expiration tied to the approved release.
- Bind the approval to a specific artifact, environment, and pipeline run.
- Revoke or invalidate the credential after the publish step completes.
A useful rule is that the approver should be deciding whether to publish, not acting as the bearer of a standing credential. If the process depends on copying a token into a chat message, a browser session, or a local shell, the control is already too loose.
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 CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Release publishing relies on short-lived secrets and token handling. |
| NHI-04 — Privilege Management | Human approval should bound publish rights to the minimum needed for the release. | |
| NHI-07 — Lifecycle and Rotation | Temporary release credentials must expire quickly to avoid standing access. | |
| Recommendation — Use short-lived release credentials and revoke them immediately after publish. Limit release approval to narrowly scoped publish privilege for one artifact and environment. Set tight expiration and rotation for any credential used in the publish step. | ||
| CIS Controls v8 | 6 — Access Control Management | Publishing access should be explicitly granted, bounded, and removed after use. |
| 5 — Account Management | The pattern depends on separating human approval from reusable privileged accounts. | |
| Recommendation — Grant publish access only for the approved release window and remove it afterward. Avoid standing privileged accounts for release publishing and use time-bound access instead. | ||
| NIST CSF 2.0 | PR.AA-03 — Identity Management and Authentication | The release gate depends on authenticating the approver before publishing authority is issued. |
| PR.AC-04 — Access Permissions and Authorizations | Publishing should be authorized only for the specific release event and scope. | |
| PR.DS-01 — Data-at-Rest Protection | Release secrets and tokens are sensitive data that must be protected from reuse and exposure. | |
| Recommendation — Require authenticated approval before issuing the temporary publish credential. Authorize publish rights for one pipeline run, artifact, and environment only. Protect release secrets so they are not stored or reused outside the approved window. | ||
| NIST Zero Trust (SP 800-207) | 3 — Zero Trust Architecture Principles | Ephemeral publish credentials and bounded approval align with zero-standing-trust access. |
| 4 — Access Control Policies | The release gate needs policy-based restriction of who can trigger publishing and when. | |
| Recommendation — Issue time-bound access and verify each release request before allowing publish. Enforce policy that only approved release events can obtain publish authority. | ||
Practitioner Guidance
What to verify: Confirm that the approval only releases a temporary credential with the smallest possible scope, and that the same approval cannot be reused for a later release. The approved action should be traceable to one pipeline run and one artifact, not to a reusable human login.
Decision rule: If the release path needs a credential that can be used again tomorrow, treat it as a standing secret and redesign it. If the credential exists only long enough to complete the publish step, the approval is doing the right kind of work.
Common mistake: Teams sometimes preserve MFA by adding a manual sign-in step to a privileged account instead of gating the release secret. That looks safer on paper, but it usually increases exposure because the account becomes a high-value target with broader access than the release actually requires.
Practitioner takeaway: The best control is not “human approval plus reusable automation access”; it is “human approval plus ephemeral publish authority.” That keeps the release governed by people while keeping the underlying CI/CD path machine-fast and secret-light.
Related resources from NHI Mgmt Group
- How should security teams add application security testing into Azure DevOps CI/CD pipelines without slowing delivery?
- How should security teams secure .NET applications in CI/CD pipelines without weakening release velocity?
- How should security teams handle authentication token errors in CI/CD pipelines without weakening access controls?
- How should security teams use fingerprint verification in multi-factor authentication without creating weak fallback paths?
