Security teams should request certificates at creation time, not bake them into images, cloud-init scripts, or configuration files. That approach reduces the chance that an exportable private key is exposed before the workload even starts. Use automation tooling to create the instance, then enroll the certificate immediately so the credential is unique to that workload and only exists for the intended lifecycle.
Provision Certificates at Workload Creation, Not in the Image
Certificates for new containers or virtual machines should be issued after the workload is instantiated, so the private key is not baked into an image, script, or template that can be copied and reused. That shifts the trust boundary from build-time artifacts to the live instance, where the credential can be uniquely bound to the workload and expired or revoked on the same lifecycle.
Hard-coding a certificate into a golden image or bootstrap script usually creates reuse risk, key exposure risk, and poor revocation hygiene. A certificate that is shared across many instances or persists beyond the intended workload lifecycle undermines both isolation and accountability.
The practical model is to automate instance creation, then trigger certificate enrollment immediately through the platform or an enrollment service. When the certificate is minted just in time, the workload starts with credentials that match its identity, environment, and lifespan instead of inheriting a secret from the build pipeline.
Why Just-in-Time Enrollment Is Safer Than Baked-In Secrets
Embedding certificates in images or cloud-init files turns a deployment artifact into a secret distribution channel. If the image is cloned, inspected, or leaked, every copy may carry the same private key material, which is especially dangerous for containers that are rapidly replicated or VMs that are frequently rebuilt.
Just-in-time enrollment reduces blast radius because each workload can receive its own certificate and private key, often with short validity and a clear owner. That makes rotation, renewal, and revocation operationally manageable instead of requiring a risky search-and-replace across images, scripts, and repositories.
For container environments, this pattern also aligns with secretless or externalized credential models where the workload proves itself at runtime and retrieves identity material only when needed. For VM fleets, the same principle applies: the instance should request its certificate after boot, not inherit a static credential from the image pipeline.
What a Secure Provisioning Flow Looks Like
A strong flow separates provisioning, identity proofing, and certificate issuance. The platform creates the instance, the workload proves its runtime context, and the certificate authority or enrollment service issues the certificate only after the request is authenticated and authorized.
This is where automation matters. You want an orchestration step that can coordinate instance creation with enrollment, then store or inject the credential only into the runtime boundary that needs it. That usually means a short-lived bootstrap credential, a workload attestation step, or an integrated enrollment protocol rather than a human copying PEM files into a script.
For containerized systems, tools such as SPIFFE and SPIRE can provide workload identity and automated certificate issuance, while certificate lifecycle practices and CA policy govern renewal and rotation. For VMs, the same design goal is to keep the private key local to the instance and avoid ever placing it in an image layer, user data blob, or configuration management file.
Risk and Threat Considerations
The main risk is credential reuse at scale: once a private key is embedded in a reusable artifact, compromise of one artifact can expose every workload built from it. That creates a broad attack surface for theft, replay, impersonation, and lateral movement.
Failure mechanism: The secret exists before the workload exists, so attackers, operators, or pipeline tooling can extract it from source control, build output, registry layers, backups, or logs before revocation is even possible.
Impact: A leaked certificate can authenticate as the workload itself, collapse environment isolation, and make incident response much harder because the compromised credential may be shared across many instances or versions.
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 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-57 and NIST SP 800-190 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Baked-in certificates create long-lived reusable credential risk for new workloads. |
| NHI-02 — Secret Leakage | Hard-coded certs in images or scripts expose private keys through build and distribution paths. | |
| NHI-06 — Insecure Cloud Deployment Configurations | Embedding credentials in deployment artifacts is a cloud deployment misconfiguration risk. | |
| Recommendation — Issue workload certificates just in time and enforce short validity with automated renewal. Keep private keys out of images, cloud-init, and repositories; generate them at runtime. Move certificate enrollment into orchestration and remove secrets from deployment templates. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificates are authenticators whose lifecycle must be generated, protected, rotated, and revoked. |
| IA-9 — Service Identification and Authentication | Containers and VMs authenticate as services or workloads using certificates. | |
| Recommendation — Automate authenticator lifecycle and issue unique certificates per workload. Bind each workload certificate to its runtime identity and authenticate it at issuance. | ||
| NIST SP 800-57 | Key Management Lifecycle | The question is fundamentally about key and certificate lifecycle handling at creation time. |
| Recommendation — Apply lifecycle rules so private keys are generated, stored, and retired per workload. | ||
| NIST SP 800-190 | Container Security Guide | Container images and runtime bootstrap are central to the certificate handling risk. |
| Recommendation — Keep secrets out of container images and provision them only at runtime. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Leaked or reused certificates can become a broken authentication path for workload access. |
| Recommendation — Use unique certificate-based authentication per workload and rotate compromised credentials promptly. | ||
Practitioner Guidance
What to prioritise: Make certificate enrollment part of the instance bootstrap path, not part of image creation. If the certificate can be copied with the image, it is already too early.
What to verify: Confirm that the private key is generated per workload, stays off shared build artifacts, and has a clear renewal and revocation path. Validate that new instances cannot start with a stale or duplicated certificate.
Common mistake: Teams often secure the certificate file but ignore the distribution path. If the image, script, or pipeline can produce the credential, the control is still fragile.
Practitioner takeaway: Treat certificate issuance as a runtime identity event, not a packaging step, and design the workflow so each workload receives unique, short-lived credential material only after it is created.
Related resources from NHI Mgmt Group
- How should security teams manage Kubernetes secrets when containers need frequent access without hard coding credentials?
- How should security teams handle sensitive values in traffic policies without hard-coding them?
- How should security teams build minimal Docker containers for security tooling without carrying unnecessary build dependencies into production images?
- How should security teams create and save new login credentials so users can sign up quickly without weakening password hygiene?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
