Lock Secrets: Stop Accidental Edits and Revocations on Production Credentials
Most credential outages in production don't come from external hackers. They come from someone on the team cleaning up on a Friday afternoon. Here is why we added asset locking to CertLocker, and how it keeps critical secrets safe without getting in the way of running workloads.
If you run production systems for long enough, you see the same incident play out over and over:
- An engineer is tidying up what looks like an old test secret, clicks revoke, and suddenly the background billing worker drops dead because it was still using that password.
- Someone tweaks a database secret in place during a hurried hotfix, forgetting that edge proxies and two internal APIs share the exact same group.
- Two people rotate an SSL key around the same time. The second save wipes out the first, and half your Nginx fleet gets stuck on mismatched PEM files.
The problem is how secret tools handle permissions. If you use Vault, AWS Secrets Manager, or Kubernetes, write access is almost always all-or-nothing for a path or namespace. If an engineer has write permissions in prod, they can edit or delete any secret in prod. There is no simple way to say: "This database password is wired straight into our core database. Do not touch it unless you really mean it."
We built secret version history earlier this year so you can roll back bad edits in one click. But rolling back an outage is still an outage. It is much better if the accidental edit or fat-fingered revoke never happens in the first place. That is why we added Asset Locking.
Spotting locked secrets right away
When you lock a secret in CertLocker, it gets a small lock mark right next to its name in the table. Unlocked and locked rows stay lined up cleanly so the table is easy to scan, but you can immediately see which credentials are frozen.
What happens when you lock a secret?
Locking isn't just a badge or a UI tooltip. The backend actively blocks changes:
- Edits are refused: Any API call to modify the secret fails on the spot with
This asset is locked and cannot be changed. - Revoke and suspend are blocked: Calls to revoke or suspend are rejected. In the web UI, the Revoke and Suspend buttons are hidden from the drawer completely so nobody clicks them by mistake.
- Version history is protected: You can't delete archived version snapshots while the secret is locked. The history stays intact.
- Clear attribution: Open the detail drawer, and it tells you exactly who locked it and when.
What happens if someone tries to edit it?
If an engineer opens the Edit tab on a locked secret, the inputs are completely disabled. The name, description, groups, and the secret material itself (whether it is a PEM key, a password, or API credentials) are grayed out.
The only active control is the Lock checkbox itself. You can't paste a new key or edit a config string by accident without first making a deliberate decision to uncheck that box and unlock the asset.
You can still inspect past versions
Locking a secret does not hide its history. If you need to see what certificate was running last week or check what key was in place before a migration, you can open the Versions tab anytime.
You can inspect earlier snapshots, check crypto metadata (like RSA 2048 or ECDSA curves), and compare values. The only thing you can't do while the lock is on is prune or delete those old versions.
Locked secrets still work for apps and servers
The first question people usually ask is: "If I lock a secret, does it break my deployments or background jobs?"
No. Locking stops mutations, not reads. The secret is not suspended, and it is not revoked.
- Automated delivery routines keep delivering PEM files and passwords to target servers over scoped SSH or SFTP.
- Scoped Team Tokens and API tokens configured for that secret keep pulling credentials as normal.
- Health probes and endpoint checkers keep verifying that servers are serving the right files.
Your apps, servers, and automated pipelines keep running. Human mistakes just can't break them by editing the secret under their feet.
Clear audit log for compliance
Every lock and unlock action goes straight to the central audit log. When an auditor asks how you prevent team members from altering production credentials without approval, you can pull up the log entry.
It records who engaged the lock, their email, the timestamp, and the asset ID. If someone unlocks it later for a planned rotation, that unlock event is logged right alongside the subsequent edit and re-lock events.
Who gets to toggle the lock?
Locking is tied to role permissions. To lock or unlock a secret, an operator needs either tenant super-user status or both the secret edit permission and the specific SECRET_LOCK role.
We also use this exact same lock across the rest of the platform: TLS certificates (CERT_LOCK), deployment hosts (HOST_LOCK), delivery tokens (TOKEN_LOCK), ACME clients, and DNS providers. If an asset is critical to keeping production alive, you can lock it.
Bring your workflow
See how CertLocker handles production credentials
If you are dealing with secret sprawl, shared PEM files, or certificate renewals across a messy mix of Linux, Windows, or cloud hosts, let's talk. We can jump on a video call or meet face to face, look at how your team handles credentials today, and walk through hosted CertLocker SaaS.
Arrange a walkthrough →