Secrets management for platform engineering in 2026

In 2026, "secrets management" means more than putting passwords in an encrypted store. The typical platform team is dealing with Kubernetes secrets, cloud secret managers, Terraform variables, GitHub Actions secrets, Ansible Vault files, SSH keys, TLS private keys, ACME account credentials, VPN files, service account tokens, and a few old scripts nobody wants to touch.

The work has moved from storage to control. Who owns each credential? Which service uses it? Can it rotate without downtime? Can a host pull only the certificate it needs? Can an AI agent read one secret without receiving a production admin credential? Can the audit trail prove what changed?

The 2026 baseline

A platform-grade secrets management model should cover five jobs:

1. Inventory: know what credentials exist, who owns them, what environment they belong to, and what systems consume them.
2. Access control: give humans, machines, CI jobs, and agents only the secret or certificate material they need.
3. Rotation: change values safely, update downstream systems, preserve version history, and support rollback.
4. Certificate workflow: issue, renew, deliver, reload, and verify TLS certificates instead of storing PEM files as anonymous blobs.
5. Evidence: record who read, changed, restored, delivered, approved, or denied each operation.

Why DevOps teams struggle with secrets management tools

Most tools solve part of the problem. They may store secrets well. They may integrate with CI. They may support cloud-native rotation. They may expose an API. But real infrastructure is not a clean diagram.

A practical estate has branch servers, old Windows services, Linux VMs, HAProxy edges, Nginx, Apache, IIS, Java keystores, Docker jobs, OpenStack, AWS, GCP, Azure, supplier portals, and private networks. Some credentials are read by people. Some by machines. Some by agents. Some are embedded in deployment jobs written years ago.

The recurring failures are predictable:

• Teams centralize storage but not ownership. The secret is in a vault, but nobody knows who approves rotation.
• Rotation breaks consumers. The platform changes the credential but the service does not reload, or only half the fleet receives it.
• Certificates are treated as files. A PEM is stored safely, but expiry, chain, SANs, endpoint state, and reload evidence are not tracked.
• Automation tokens are too broad. CI jobs and agents get credentials that outlive the task and reach too much infrastructure.
• Audit logs are fragmented. Secret reads, certificate renewal, host access, and probe results live in separate systems.

Centralizing secrets with certificate workflows

The strongest platform model treats TLS certificates as operational objects, not just secret files. A certificate has sensitive material, but it also has lifecycle state. It needs an issuer, validation, renewal, delivery, reload, probe, and evidence.

This matters more as certificate lifetimes shorten. A 90-day certificate was already too frequent for manual tracking. Shorter lifetimes push teams toward full automation. If the secret manager and the certificate manager do not agree about ownership, tokens, private keys, and delivery, the team will spend the next few years wiring glue between tools.

A cleaner workflow looks like this:

1. The platform stores the private key, ACME account material, DNS token, or deployment credential as a governed secret.
2. The certificate lifecycle workflow issues or renews the certificate.
3. A host, agent, or deployment job receives a scoped token for exactly the certificate or secret it needs.
4. The target service reloads or restarts using the new material.
5. An endpoint probe confirms what production is serving.
6. The audit trail links the secret access, certificate renewal, delivery, reload, and probe result.

Evaluation checklist for 2026

Where common DevOps tools fit

HashiCorp Vault is a strong general-purpose platform for secrets, dynamic credentials, and PKI when a team can operate it properly. That operating cost is real. It needs ownership, high availability, policy design, backup, upgrades, and a team comfortable with Vault internals.

AWS Secrets Manager, Google Secret Manager, and Azure Key Vault make sense for workloads that live inside their respective clouds. They become less clean when the infrastructure spans multiple clouds, private networks, on-prem systems, and non-cloud deployment targets.

Doppler and Infisical are strong options for developer-centric secret workflows. Infisical also has certificate management capability. The question for platform teams is whether the tool can manage the full infrastructure chain: certificate renewal, host delivery, reload, probes, SSH/RDP access, and audit evidence across the systems they actually run.

cert-manager is the right default for many Kubernetes certificate workflows. It does not solve certificates on old IIS boxes, HAProxy edges, bare metal, vendor portals, or branch systems by itself.

How CertLocker approaches it

CertLocker is built around the operational model platform teams need when secrets and certificates meet real infrastructure. Secrets are not isolated from certificates. Certificates are not isolated from delivery. Delivery is not isolated from endpoint verification. Access is not isolated from audit.

That gives teams one place to manage:

• Secrets with version history, RBAC, and audit logs.
• TLS certificate lifecycle, expiry, renewal, and ownership.
• Scoped certificate delivery for hosts and automation jobs.
• Endpoint probes that confirm production is serving the expected cert.
• Short-lived SSH and RDP access for infrastructure operations.
• Scoped MCP access for AI agents instead of handing raw credentials to tooling.

What a one-month evaluation should prove

A secrets management evaluation should not stop at "can we store a password?" That proves almost nothing. A platform team should test a workflow that looks like production.

Bring a messy but representative slice:

• One public TLS service with renewal and endpoint probe.
• One internal service where the certificate is delivered to HAProxy, Nginx, IIS, or a Java keystore.
• One deployment secret that currently lives in Ansible Vault, GitHub Actions, a shared file, or an old script.
• One SSH or RDP access workflow that should become scoped and short-lived.
• One audit question you currently cannot answer cleanly.

If the platform can handle those five cases, you are testing the real control plane. If it only stores values and returns them over an API, you are testing a database with better access control.

Primary sources for current behavior

• HashiCorp Vault PKI secrets engine
• Infisical certificate management
• Doppler rotated secrets
• cert-manager documentation
• Smallstep step-ca