The Enrolment Ceiling: a maturity framework for provenance and signing identity
Every signed provenance claim, from a code-signing certificate to a C2PA manifest to a proposed “proof of human” credential, is only ever as trustworthy as the weakest check performed at the moment someone was allowed to start signing. This document formalises that observation into something you can audit a system against: six pillars, a five-level maturity model, the objections worth taking seriously, and a direct mapping against the EU AI Act’s Article 50 marking duty, which is currently the closest thing to binding law in this space.
It grew out of a piece on the forged aviation certificate fraud run by Jose Alejandro Zamora Yrala between 2019 and 2023, sentenced in February 2026. That case is used here only where it earns its place. The framework itself is meant to outlive any single incident.
The mechanism
The maximum trustworthiness of a signed claim is bounded by the identity check performed at enrolment, and nothing downstream can raise it above that bound. A signature proves that whoever held a key made an assertion. It says nothing about the process that decided who was allowed to hold the key. Strengthen the cryptography, tighten the revocation window, add a hardware module: none of it touches the ceiling, because the ceiling was set the day the key was issued.
Aviation illustrates this cleanly because the rest of its system was genuinely strong. Zamora Yrala forged over 60,000 airworthiness certificates for CFM56 engine parts from a home office in Surrey, over four years, and the certificates were good enough to pass. He didn’t defeat aviation’s regulatory apparatus. He simply operated outside the part of it that checks who is allowed to issue a certificate in the first place, and nothing else in the system was built to catch that.
The same pattern shows up without any human forger at all. In December 2020, a build system belonging to SolarWinds was compromised and used to insert malicious code into Orion software updates that were then legitimately signed and distributed to an estimated 18,000 organisations, including US federal agencies. The code signing worked exactly as designed. Every downstream verification step passed. The compromise happened upstream of the signature, in the system that decided what was allowed to be signed, which is the enrolment layer for a build pipeline rather than for a person.
Two different domains, four decades apart, no shared technology, same failure point. That is what makes this a mechanism rather than an anecdote.
The six pillars
Each pillar below is a question a provenance system has to answer honestly. Most systems in production today answer some of them well and leave others completely open, which is exactly the condition the objections section addresses later.
1. Identity proofing strength
Who checked the identity behind this key, and how hard did they check? Zamora Yrala invented fictitious quality managers who “confirmed” his forgeries by email, and nobody on the buying side verified those people existed. TLS at least has a tiering convention for this problem: domain validation, organisation validation, extended validation, each requiring progressively more identity checking before a certificate authority signs. Content-authorship credentials have no equivalent convention yet. A “verified human” badge and a “somebody typed an email address” badge currently look identical.
2. Custody separation
Can the party making a claim also unilaterally issue the credential that backs it? Zamora Yrala forged his certificates himself, on his own computer, with no organisation-controlled step in between. SolarWinds shows the same gap in software form: the build system that produced the update and the authority that signed it were close enough together that compromising one compromised the other. Keyless signing schemes like Sigstore genuinely help here, binding a signature to a federated identity token rather than a key on someone’s laptop. That solves custody. It does nothing for pillar one.
3. Revocation latency
Once fraud is suspected, how long before nothing downstream trusts the credential any more? CFM’s own count of forged documents kept growing for months after discovery in 2023, because the only kill mechanism was a manual, escalating chain of safety bulletins. PKI has the equivalent problem built in structurally rather than as a one-off failure: a certificate revocation list or an OCSP responder is only as current as its last publish cycle, and plenty of clients cache a stale answer rather than check live. The industry’s actual answer to this, where one exists, has been to shorten certificate lifetimes rather than speed up revocation, which is a tacit admission that fast revocation is hard to guarantee.
4. Verification enforcement
Does anyone downstream actually check, or is the badge trusted on sight? Aviation buyers had the ability to verify a certificate directly with the named manufacturer for the entire four years of the fraud. Almost nobody did it, until one maintenance shop in Portugal checked one part. The same gap sits inside plenty of CI/CD pipelines that mandate cosign verify for new services and quietly leave every legacy pipeline unverified, because retrofitting is expensive and nobody wants to be the one who breaks the release train chasing a theoretical risk.
5. Attestation liveness
Does the credential describe a moment, or a current state? An EASA Form 1 attests to a part’s condition at release, not that the specific piece of metal in front of an engineer today still matches it. C2PA deserves credit here: it hashes the bytes at signing, so any edit to that exact file breaks the chain visibly. What it cannot catch is the file being fed back through a generator and resubmitted as a fresh original. Nothing about a valid signature distinguishes a first-generation human file from a fifth-generation laundered one, and this is the single hardest unsolved problem for any “proof of human” concept currently on the table.
6. Economic pressure inversion
What happens the moment this attestation is worth money? Zamora Yrala’s fraud generated roughly £6.9 million over four years by undercutting genuine certified parts while looking identical on paper. will.i.am’s own framing for “proof of life” is explicitly economic: stop human and AI output being valued at the same fraction of a penny. That is the precondition for exactly the fraud aviation just spent four years cleaning up, at a moment when Deezer alone was receiving close to 90,000 fully AI-generated tracks a day. A pricing decision that creates a premium for “verified human” without first closing pillars one through five is choosing to fund the attack.
The maturity model
Score a system pillar by pillar, then take the lowest score as the system’s real maturity level. A system with five pillars at level 4 and one pillar at level 1 is a level 1 system, because that is the level an attacker will target.
| Level | Name | What it looks like | Where it shows up today |
|---|---|---|---|
| 0 | Self-declared | Identity or authorship is simply stated, with no check and no record of one having occurred. | Most AI-disclosure metadata in music distribution today: the uploader ticks a box. |
| 1 | Recorded, unverified | Identity is captured and stored at enrolment, but never independently confirmed against an external source. | Typical account-based sign-up flows; most self-issued code-signing certificates. |
| 2 | Tiered proofing, no enforcement duty | A real identity-proofing tier exists (document checks, organisation validation, notarisation), but relying parties are not required to check which tier backs a given claim before trusting it. | Enterprise PKI with mixed-tier certificate authorities; C2PA manifests that carry an identity assertion but leave verification optional for the consuming platform. |
| 3 | Enforced verification, slow revocation | Verification is required at the point of use, and a revocation mechanism exists, but revocation runs on a manual or batch process measured in days to months. | Mature enterprise code-signing environments; most aviation parts certification prior to the AOG Technics case; current EU AI Act Article 50 marking as implemented. |
| 4 | Live attestation | Verification is enforced at point of use, revocation is near real time, and the claim is bound to a freshness check rather than a static point-in-time signature. | Not fully achieved by any system covered in this document, aviation, PKI, or content provenance. Named here as the target state, not a claim that one exists. |
Placing familiar systems on this scale is uncomfortable on purpose. Aviation’s parts certification regime, with sixty years of regulatory investment behind it, sits at level 3, not level 4, and that is what let a four-year fraud run at 60,000 parts before anyone noticed. C2PA’s technical design can reach level 3 where an implementer chooses to enforce identity checking on manifests, but ships closer to level 1 or 2 by default, because identity proofing is left to whoever adopts the standard. Nothing pitched as “proof of human” so far, including will.i.am’s, has published enough detail to be scored at all.
Objections worth taking seriously
A framework that only survives friendly questions is not worth publishing. These are the strongest counterarguments, addressed honestly rather than dismissed.
“This is just PKI theory with a new name.” Largely true, and that is the point. PKI paid for these lessons decades ago. The value here is naming the composite ceiling so that newer provenance efforts, content credentials, “proof of human” formats, do not have to relearn pillars one through five from scratch, or worse, skip them because nobody named them as a checklist.
“C2PA’s Creator Assertions work already covers identity.” This is the strongest objection in the document. The Creator Assertions effort within the C2PA ecosystem is a genuine, serious attempt at pillar one, and it deserves to be treated as the current leading answer rather than ignored. The caveat is that it is opt-in and does not currently mandate a minimum proofing tier, so a manifest can carry a technically valid creator assertion built on nothing stronger than an unverified account. The mechanism is there. The enforcement is not, yet.
“Watermarking solves this without needing identity at all.” True for a different question. SynthID-style watermarking answers “was this generated by a specific model,” at genuinely large scale, over 100 billion images and videos marked as of mid-2026. It cannot answer “did a human make this,” because that was never what it was built to detect. Watermarking and enrolment-based identity are complementary tools solving different problems, not substitutes for each other.
“Aviation’s apparatus took sixty years and real casualties to build. Nobody will fund that for content.” This one deserves to be conceded rather than argued away. The political will behind aviation’s regime came from consequences nobody wants repeated in the content world. The EU AI Act and the US NO FAKES Act are the first real forcing functions here, and neither currently mandates an enrolment-tier standard. Whether that changes is genuinely uncertain, and this document does not claim to know.
“A signature is better than nothing, so partial implementation still helps.” This is the one worth resisting hardest. Shipping pillar one alone, a signature with no custody separation, no enforcement duty, no revocation plan, and no freshness check, creates a badge that gets trusted by default because it looks complete. That’s a worse outcome than declaring the content unverified: perceived trust rises faster than actual trust ever does, and the gap between the two is exactly where fraud lives. Partial implementation of this framework has a specific, documented failure mode.
Mapped against EU AI Act Article 50
Article 50’s transparency obligations became enforceable on 2 August 2026, with a grace period for provider-side marking of pre-existing systems running to 2 December 2026. It requires machine-readable marking of AI-generated content and disclosure where synthetic material could be mistaken for authentic. It is currently the closest thing to binding law touching this framework, and it is worth being precise about what it does and does not require.
| Pillar | What Article 50 requires | What it leaves open |
|---|---|---|
| 1. Identity proofing | Nothing specific. The obligation is to mark content, not to verify who is behind the mark. | No minimum proofing tier for whoever applies a “human-made” or “AI-generated” label. |
| 2. Custody separation | Nothing specific. | No requirement that the party making content and the party attesting to its origin be separated in any way. |
| 3. Revocation | Nothing specific. | No mechanism to invalidate a mark once it is discovered to be false, unlike aviation’s safety information bulletin process. |
| 4. Enforcement | Providers must mark; some downstream disclosure duties apply to deployers. | No explicit duty on every downstream platform to verify a mark before relying on it, though the US NO FAKES Act creates indirect pressure through platform liability of up to $750,000 per work. |
| 5. Liveness | Marking is applied at generation time. | No re-check built in as content is edited, transcoded, or re-shared. Watermark survival through common transformations remains an open technical problem industry-wide. |
| 6. Economic pressure | Out of scope entirely. Article 50 is a disclosure regulation, not a rights or monetisation framework. | This is exactly the gap will.i.am’s “proof of life” pitch is trying to occupy, and it would inherit every open item above it, since nothing in Article 50 closes them first. |
Article 50 regulates marking behaviour without regulating the enrolment layer underneath it. A compliance programme that treats Article 50 marking as a finished job is stopping at, at best, pillar one on the maturity model above. Per the objections section, that is the half-measure that raises perceived trust without raising real trust.
How to use this document
Score your own system against the six pillars honestly, not aspirationally. Find the lowest-scoring pillar. That is your system’s real maturity level, regardless of how strong the other five are, and it is where an attacker with any patience will look first. If you are being asked to add a “proof of human” or provenance capability to a pipeline in the next 18 months, use the table under Article 50 to show what the regulation actually requires versus what it silently assumes someone else has already built.
The framework, in one line: build the enrolment layer before you build the badge.
Bola Ogunlana is a Senior DevSecOps Engineer with 25+ years in cloud infrastructure, UK Government delivery, and financial services. He writes at blog.ogunlana.net. This framework accompanies “The forged certificate problem is coming for AI content provenance too,” published in the Cockpit to Cloud series.