The custodian problem: sealed-key custody is a platform decision, not a feature

A credential is only as trustworthy as the custody of the key that signed it. Everything downstream — verification, revocation, aggregation, portability — inherits this one assumption. If the issuer key is exfiltrated, casually held in an environment variable, or reachable by any process that can call Sign, then every credential ever produced under that key is forgeable and every revocation is suspect. You cannot fix this with a better blockchain, a better verifier, or a better wallet. The damage is already in the trust root.

Most credentialing platforms treat key custody as a feature toggle, a dev-ops detail, a line item in a deployment checklist: “use a KMS,” “rotate annually,” “store secrets properly.” That framing is a category error. Custody is not a thing you configure after you’ve built the platform. Custody is the platform decision — it determines your trust posture, your threat model, your blast radius, your theory of who is trusted, and your economic position in the credentialing supply chain. Everything else is downstream of it.

I run these keys. The Mneurix Lattice issuer uses a sealed-key custody model with a boot-guard pattern: the issuer key is sealed at rest, unsealed only when a boot-guard asserts that the running image is the approved, pinned issuer binary, and the key never leaves that boundary. We made this choice early and deliberately, and we did not delegate it. This essay explains why custody is a platform decision, what the sealed model closes that the thin model leaves open, and why the difference matters not just for security but for who controls the supply side of credentialing.

The load-bearing assumption

When a verifier checks a credential, she is checking two things: that the signature is valid, and that the key that produced it is a key she should trust. The second question is where custody lives. A key she should trust is a key that was held in a way that made exfiltration improbable and unauthorized use impossible. If the answer to that question is “it was in an environment variable and any application process could sign with it,” then the first question — the signature math — is doing theater. The signature is valid; the trust is not.

This is the load-bearing assumption the whole stack inherits. Revocation lists assume the issuer key is intact — if it’s compromised, the attacker can suppress or forge revocation entries. Aggregation assumes the issuer is a credible root — if the key walked out the door, aggregating credentials under that root just aggregates forged credentials. Portability assumes the credential’s provenance is intact — but if the key was casually held, provenance is unverifiable by construction.

The point is that custody is not the last mile of credentialing. It’s the first mile. It’s the decision from which everything else gets its meaning.

Why custody is a platform decision, not a feature

A feature is something you add. Custody is something you commit to. The distinction matters because the custodial model determines the platform’s irreducible properties — the things you cannot change later without breaking what you’ve already built.

Consider rotation. If your custody model assumes keys can be rotated freely, you’ve implicitly accepted that every credential issued under a retired key must be re-issued, re-verified, or rendered unverifiable. That’s not a dev-ops task. That’s a trust event — every holder of every credential under the old key now has a problem they didn’t cause. Rotation has blast radius. If your platform issued a million credentials and the key needs to rotate because of a near-miss compromise, you are now in a race against an attacker who may already have the key. You’re asking a million people to trust that re-issuance is legitimate. That’s a platform-level event, not a feature.

Consider interop. If your custody model is “the key lives in a cloud KMS and the application calls Sign,” then your interop story is: any platform that can call your KMS can mint your credentials. Maybe you’ve scoped the IAM policy. Maybe. But the trust boundary is the KMS policy, not the issuer’s identity. The question “who can produce a credential that verifiers will accept as ours” is answered by your IAM configuration, not by your platform architecture. That’s fragile and it’s invisible to verifiers, which is the worst combination.

Consider the theory of trust. A custody model encodes a theory of who is trusted to produce credentials and under what conditions. Thin custody says: the application is trusted. Sealed custody says: a specific running image, attested by a boot guard, is trusted — and only that image, only at boot, only within the boundary. These are different theories of trust, and they produce different platforms. You don’t add sealed custody as a feature to a thin-custody platform; you rebuild the platform around it.

The choice we made with the Lattice issuer was to commit early: the key is sealed, the boot guard pins the image, and the key is usable only within that attested context. That decision shaped the issuer’s deployment model, its update pipeline, its threat surface, and the promises we can make to verifiers. It was a platform decision. We couldn’t have bolted it on later without re-issuing everything and re-earning the trust of every verifier who’d already accepted our root.

Thin custody vs. sealed custody

Thin custody: the issuer key lives in an environment variable, a secrets manager, or a KMS, and the application can call Sign more or less freely. The trust boundary is the application’s access control. The key may be “managed” but it’s not sealed — it’s reachable by any process in the trust envelope, and the trust envelope is usually larger than anyone admits.

Sealed custody: the key is sealed at rest, unsealed only when a boot guard asserts that the running image is the approved, pinned issuer. The key never leaves the boundary. The trust boundary is the attested boot context — a specific binary, a specific hardware context, a specific moment. The key is not “managed.” It is entombed until a precise condition is met, and then it is usable only within that condition and never exits it.

The threat sealed custody closes that thin custody leaves open is the issuer-impersonation class: an attacker who gains application-level access can mint credentials indistinguishable from genuine ones because they are genuine ones — they’re signed by the real key, through the real signing path, with the real key material. The credentials are not forged in the cryptographic sense. They are forged in the trust sense: they were produced by an actor who was not the issuer, using the issuer’s own key, because nothing in the custody model distinguished the issuer from an attacker with app-level access.

Thin custody can’t close this class because the threat model it assumes is “protect the key from external theft.” Sealed custody closes it because the threat model it assumes is “protect the key from unauthorized use, including by processes that have legitimate access to the signing environment.” The distinction is between protecting a secret and protecting an authority. Sealed custody protects authority.

The Blockcerts lesson

Blockcerts is the canonical negative example, and it’s worth being precise about what went wrong. The Blockcerts issuer-impersonation class: a compromised or reused issuer key mints credentials that are indistinguishable from genuine ones. The blockchain records them faithfully. The chain is doing its job. The signature is valid. The key is the real key. The credentials are still forged.

This is not a failure of the chain. It’s not a failure of the signature scheme. It’s a failure of custody, and specifically the assumption that custody is a feature — something you handle with a config file and a secret store. The Blockcerts model put issuer keys in configurations that were, in practice, movable. An issuer could place their keys in a JSON file, rotate them into a new environment, reuse the same keypair across revocation-address generations, or hand the whole config to a second operator and call it portability. The blockchain recorded every credential faithfully. The revocation list was correct. The signatures verified. The chain did its job.

And yet: if an attacker copied that config — from a developer laptop, from a misconfigured S3 bucket, from a CI runner that logged a build secret — they could mint credentials indistinguishable from the genuine issuer’s. The chain would accept them. The wallets would display them. The verifiers would pass them. The credentials were forged. The blockchain didn’t prevent it, couldn’t prevent it, and was never designed to. The custody layer was the failure, and the consensus layer dressed it up as a success.

This is the lesson I keep coming back to: you can’t config-file your way out of custody. The Blockcerts ecosystem treated issuer-key configuration as a packaging problem — a thing you documented in a README and templated into an installer. But custody is not packaging. Custody is the thing that decides whether the issuer is who the credential says it is. When custody is thin — when the key is a file that moves — the credential’s authority is a file that moves. Everything downstream inherits that mobility, and the blockchain’s tamper-evidence becomes a perfectly faithful record of forged authority.

We didn’t build our platform that way. We chose sealed custody because the alternative was inheriting this failure mode by default. You can read the negative-result rationale for that decision in the companion piece at learn — the short version is that every chain-based approach we evaluated reduced to “the custody problem, plus a ledger,” and the ledger didn’t help the custody problem at all. The chain was a cost we’d pay to inherit exactly the failure mode Blockcerts surfaced.

The supply side of credentialing

Here’s where it gets economic. Credentialing platforms are supply-side businesses. The value accrues to whoever holds the credible issuer relationships — and credible issuer relationships are a custody question before they’re a product question, a UX question, or a protocol question. If your platform’s issuer keys can be walked off with, your platform cannot be the aggregation point. You can build the best verifier, the cleanest wallet, the most elegant schema, and it doesn’t matter, because the supply side — the issuers who give the platform its reason to exist — have no reason to route through you if your custody posture means their authority is negotiable.

This is why I think about it as aggregation theory for credentials: the platform that owns credible custody owns the supply side, and the supply side is where the moat is. A platform whose keys are portable in the Blockcerts sense isn’t aggregating — it’s hosting files. The credentials pass through, but the trust doesn’t pool. There’s nothing to aggregate, because there’s no credible commitment from the platform that the issuer identity it’s routing is the issuer identity that actually signed.

The defensible position is the one that requires standing somewhere specific. This is the argument I made in building in the gap: you don’t build a durable platform from the bleachers. Custody is that specific place. Sealed custody — boot-guard, measured boot, key material that physically cannot be extracted from the facility — is a commitment to standing in a particular location, accepting a particular blast radius, and taking responsibility for a particular set of residual risks. You can’t reason about custody from the bleachers. You can’t outsource it to a config template. You either stand in the facility or you don’t, and the platform economics follow that choice.

What sealed custody doesn’t solve

I want to be honest about what sealed custody doesn’t solve.

Boot-guard and sealed-key custody are not a panacea. The residual risks are real and I think about them daily. A supply-chain compromise of our build pipeline — a poisoned dependency, a tampered compiler, a signed-but-malicious image — could subvert the sealed-key system before the keys are ever provisioned. An image-signing key compromise could let an attacker ship a fraudulent attestation environment that the sealed platform would faithfully boot and faithfully protect the keys inside. We’ve layered signing on signing, reproducible builds on measured attestation, and still: the trust chain has a root, and the root is a set of decisions made by people with access to build infrastructure. That’s not eliminable. It’s a risk we carry.

The point isn’t perfection. The point is that custody was treated as a platform decision — argued over, costed, designed against — and the residual risks are now the ones the platform chose to carry, not the ones it inherited by default. That distinction matters. Inherited risk is unexamined risk. It’s the Blockcerts config file that no one audited because the chain was supposed to handle trust. Chosen risk is risk you’ve named, bounded, and built around. You can run a platform on chosen risk. You can’t run one on inherited risk, not for long, not once an attacker reads the same README.

Sealed custody is a platform decision because it constrains everything the platform can do. It means the keys can’t be portable across environments — that’s the whole point. It means the facility is a single point of failure for key availability — we accept that, and we engineer against it with redundancy inside the facility, not by making the keys mobile. It means the platform’s trust story is grounded in a physical location and a build pipeline, not in a cryptographic protocol that any node could replicate. These are real constraints. They’re the constraints that make the custody credible.

The custodian problem is not something you solve with a feature. It’s something you settle as a platform, deliberately, with the full weight of the economic and security consequences visible. We settled it by sealing the keys and building the rest of the system around that seal. The credentials that come out of our facility are credentials whose authority we can account for — not because the chain says so, but because the key that signed them can’t have come from anywhere else.

That’s the only custody posture worth building a platform on.