After the 2026 certificate authority compromise: signing authority is not key custody
Think of a code signing key like the company stamp in a drawer. Locking the drawer better — which is what hardware key storage does — does not answer the question of who decided this particular document deserved the stamp.
Is holding the signing key the same as authorising a signature?
No, and a 2026 certificate authority compromise made the distinction expensive. Stolen code-signing certificates were used to sign malware. Hardware key storage improved custody — the key never left its module — and did nothing to establish that a human approved that specific artefact.
- A code signature proves the signing key was used. It does not prove a human approved the artefact, because signing is automated by necessity.
- Under four compromise scenarios, key custody controls address two and leave two open.
- A release approval receipt bound to the artefact hash is verifiable by downstream consumers alongside the signature.
Part of Machine and signing identity
What a code signature actually tells you
When your operating system tells you a program is signed by a company, it has verified a chain: the signature was produced by a key, the key is certified by a certificate, and the certificate chains to an authority the system trusts.
Everything in that chain is about custody — who holds the key and who vouches for them. Nothing in it is about intent. The system cannot tell you whether anyone at the company looked at this build.
For most software that is fine, because the key is held by a company that builds software and the signature means that company shipped it. It stops being fine when someone else can reach the key or the service that uses it.
What happened in 2026
Reporting in April and May 2026 described a certificate authority compromise in which code-signing certificates were stolen and used to sign malware, including stealer and remote-access payloads, for the purpose of evading detection. The CA/Browser Forum's code signing baseline requirements were updated again in June 2026, continuing a trajectory of shortened validity periods and tightened key protection requirements.
The industry response concentrated on custody: stronger key storage requirements, shorter certificate lifetimes, tighter issuance vetting. All sensible, and all addressing the same half of the problem.
Four compromise scenarios
| Scenario | Key custody controls help? | Approval evidence helps? |
|---|---|---|
| Key exfiltrated from a developer machine | Yes — HSM storage prevents extraction | Yes |
| Certificate authority compromised, certificate issued to an attacker | No — the key is legitimately held by the attacker | Yes — no valid human approval exists |
| Signing service reached by an attacker inside the network | No — the service signs what it is asked to | Yes |
| Malicious insider with signing access | No | Partially — attributes the approval to them |
Custody controls address the first row. Rows two and three are where the 2026 incidents live, and they are the rows where a separate approval artefact is the only thing that helps.
Why signing is automated, and why that is correct
A modern pipeline signs continuously: every merge, every nightly, every release candidate. Requiring a human gesture per signature would be unworkable and would produce approval fatigue, which is worse than automation.
So the design cannot be a human signs everything. It has to be a human approves the artefacts that ship, which is a much smaller set and a decision someone is already making.
The release approval receipt
{
"type": "manav-stmt/1",
"action": "release_approval",
"render": [
"Product: [name] Version: [semver]",
"Artefact: [filename] SHA-256: [hash]",
"Build: [pipeline run id] Source: [commit]",
"Provenance: [attestation reference]",
"Channel: [stable | beta | internal]"
],
"approver": "[credential assertion, role]"
}A downstream consumer verifies two things: the code signature, which establishes custody, and the approval receipt, which establishes that a named human at the publisher approved this exact artefact for this channel.
How this relates to build provenance
Build provenance frameworks attest to how an artefact was produced — which source, which builder, which parameters. That is genuinely valuable and it is a different claim.
Provenance says this artefact came from that source through that pipeline. Approval says a human decided this artefact should ship. An attacker who compromises the pipeline can produce valid provenance for a malicious artefact; they cannot produce an approval receipt without a credential held by a person.
What to do first
- Establish whether any human approval is currently bound to your last release's artefact hash. In most organisations it is not — approval is a ticket state or a chat message.
- Identify the channel that matters: what customers install, not what internal testing consumes.
- Add the approval gesture at the promotion step to that channel, not at build time.
- Publish the approver's verification key alongside your code signing certificate, so consumers can check both.
Step four is the one that turns this from an internal control into a supply chain assurance. A customer who can verify that a named human at the publisher approved the binary they are installing has something they have never had before.
What a signing request should carry
| Element | Typically present? |
|---|---|
| The artefact digest | Yes |
| The requesting pipeline | Yes |
| The approving human | No |
| What they were shown | No |
| The scope the approval covers | No |
A signing service that accepts a digest from an authenticated caller is a signing oracle. Its security reduces entirely to who can reach it, which is the property the HSM was supposed to stop being the whole answer.
Objections and honest limits
“Our HSM requires quorum for key operations.” For key management operations — generation, export, deletion. Signing requests typically pass on an authenticated API call, which is a different path.
“Every build would need a human.” Not every build. Release artefacts that ship to customers are a small fraction of builds, and those are the ones a stolen certificate is used for.
Separating custody from authority
- Identify which signing operations ship to customers. A small subset of total signing volume.
- Require a human approval on those. Bound to the artefact digest.
- Render what is being signed. Artefact, version, target, and what it will be trusted for.
- Log the approval with the signature. So the certificate and the decision travel together.
Terms used here
- HSM
- Hardware security module — a device that generates and holds keys so they cannot be exported.
- Signing oracle
- A service that will sign whatever an authorised caller submits, reducing security to access control.
- Code signing
- Signing software so that operating systems and users trust its origin.
Frequently asked questions
Does this replace code signing? No. Code signing establishes custody and integrity, and operating systems rely on it. The approval receipt is an additional artefact addressing a different question.
Would this have prevented the 2026 incidents? It would have made the malicious artefacts distinguishable: validly signed but carrying no publisher approval. Whether anyone checked is a separate question about consumer verification behaviour.
Does it slow releases? It adds a gesture at channel promotion, which is a decision a human already makes. Build-time signing is unaffected.
How does this interact with SLSA-style provenance? Complementary. Provenance attests how the artefact was built; approval attests that a human decided it should ship. A compromised pipeline can produce the first and not the second.
Did hardware key storage fail in the 2026 CA compromise? No. The keys were not extracted. The signing capability was used, which is a different property.
What is a signing oracle? A service that signs whatever an authorised caller submits. Its security is entirely access control, which is what the HSM was meant to supplement.
Does every build need approval? No. Release artefacts shipping to customers are a small fraction of builds, and they are what a stolen certificate is used for.
Where this fits in Manav
Manav anchors machine and agent authority to a named human through a signed delegation with scope, depth and enforced revocation — so an action at hop four still resolves to a person.
Sources and further reading
- CA/Browser Forum baseline requirements
- FCC — protecting consumers from SIM swap and port-out fraud
- Published supply chain attack analyses involving validly signed malicious software.
- Build provenance and artefact attestation framework documentation.
- CA/Browser Forum — code signing requirements
- OWASP — Non-Human Identities Top 10