What should security teams do when a workflow identity can obtain certificates?

When a workflow identity can obtain certificates, what changes?

A workflow identity that can obtain certificates is no longer just a build-system credential holder. It can become a trust anchor for signing, mutual TLS, or downstream authentication, which raises the consequence of compromise and makes separation of duties much harder to preserve. The question is not whether certificates are useful, but whether that identity is allowed to mint trust for anything broader than its narrow job.

Certificates are often treated as harmless plumbing because they are issued by internal automation. In practice, certificate issuance can create durable access paths, especially when the same identity can reach a CA, enroll for short-lived material, or sign artifacts that other systems trust. That is why workflow identities must be evaluated like other non-human identities, with explicit attention to authority, scope, and blast radius.

Where certificates are part of the workflow, the security boundary should follow the trust decision rather than the pipeline convenience. If a workflow identity can request or renew certificates, the issuance path should be separated from the build step, scoped to the smallest workable subject or environment, and constrained so that compromise of the workflow does not automatically translate into broader trust.

Why certificate issuance is a privilege issue, not just a tooling issue

Certificate access changes the security model because it can represent an authenticated path into other systems, not merely a file generated by automation. In a healthy design, the workflow can ask for the minimum credential material it needs, but it cannot freely expand its own authority or mint trust for unrelated services. That distinction matters most when certificates are used for code signing, service authentication, or workload-to-workload trust.

Security teams should compare the certificate capability to the job the workflow actually performs. If the workflow only needs to package, test, or publish artifacts, then direct access to certificate issuance is usually broader than necessary. If it must sign output, the signing step should be isolated, tightly scoped, and auditable, because the signing act itself is the privilege-bearing action.

This is also where lifecycle control matters. Certificates that are easy to obtain but hard to revoke, rotate, or trace increase operational and forensic risk. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide is useful when teams need to treat issuance, renewal, and expiration as part of the control design rather than as an afterthought.

How to decide whether the trust boundary is too wide

The right test is whether the workflow can obtain certificates without also gaining authority to act as something larger than intended. If the certificate can authenticate to production systems, enable signing, or impersonate a trusted workload, then the trust boundary is probably too wide unless there is a compensating control that keeps issuance tightly bounded.

Teams should look at the issuer relationship, the subject name or workload binding, the environment scope, and any reuse across pipelines. A single workflow identity that can obtain certificates for multiple environments, multiple services, or multiple purposes creates a concentration point that is easy to overlook until it is abused. NHIMG’s Guide to SPIFFE and SPIRE is relevant when you want workload identity to be bound to a stronger trust model rather than to an ad hoc pipeline secret.

The practical boundary question is simple: can the workflow obtain only the certificate it needs for this step, or can it become a general issuer for downstream trust? If it can do the latter, teams should treat that as a design defect, not a normal automation feature. NHIMG’s overview of non-human identities is a useful reference point for placing workflow identities in the broader identity model.

Risk and Threat Considerations

A workflow identity that can obtain certificates creates a high-value abuse path because certificate material can outlive a single job and can authenticate to multiple systems. If an attacker compromises the workflow, the certificate authority path, or the issuance secret, they may gain trusted access that looks legitimate to downstream services and is harder to distinguish from normal automation.

Failure mechanism: The workflow becomes a privileged issuance channel, so compromise of the pipeline or its credentials can be converted into trusted certificates, signing authority, or persistent service access. A misplaced trust boundary, broad subject scope, or weak issuance policy amplifies the blast radius.

Impact: Attackers can impersonate workloads, sign malicious output, move laterally through trusted services, or persist beyond the initial compromise by reusing issued certificates until they expire or are revoked.

Practitioner Guidance

What to verify: Confirm whether the workflow identity is allowed to request certificates only for itself, only for one environment, and only for one narrowly defined purpose. If the answer is anything broader, classify the capability as privileged and require explicit approval.

Decision rule: If the certificate can be used to authenticate to production systems or to sign artifacts consumed elsewhere, separate issuance from the build step and make the issuer path independently controlled, logged, and reviewable. If not, keep the workflow bound to ephemeral, least-privilege credentials.

Practitioner takeaway: The dangerous part is not that a workflow can obtain a certificate, it is that the certificate can become trusted identity power. Treat issuance as an authority decision, not just a delivery mechanism.

Related resources from NHI Mgmt Group

• How should security teams govern machine identity credentials in agentic AI environments?
• How should security teams manage permissions for AI agents?
• How should security teams govern AI agents that use OAuth access?
• How should security teams limit the risk from AI agents that have access to production systems?