What Actually Changes After a Product Is Certified
There is a common assumption baked into how the security industry talks about certified products: a certificate is the end of the story. The evaluator signs off, the certifying body issues the document, the vendor updates a marketing page, and from that point onward the product is “certified.” Done.
In practice, the documents that back a certification continue to move after the cert is issued. We know this because we monitor those documents. NenkinTracker continuously ingests certification artifacts from seven schemes (SESIP, CCRA, EUCC, EMVCo, PSA, ESA, MIFARE), hashes every PDF version we see, and records when a document changes after it was first published. Below is what that has actually looked like since we started watching.
The full spectrum, from cosmetic to consequential
Not every change is meaningful. A lot of what we see is noise:
PDF metadata only. A new file is published, the SHA-256 differs from the previous version, but a careful diff shows that only the document properties or producer string changed. The content is identical. We flag these so they do not surprise anyone, then close them out.
Editorial corrections. A lab name spelled differently. A footer date adjusted. A typo in a heading. These are real changes to the document, and they would silently invalidate any internal hash you might be keeping yourself, but they do not change what was evaluated or what the product actually does.
In the middle of the spectrum, things get more interesting:
Clarifications to existing report content. An evaluator updates a paragraph that was previously ambiguous. For example, a section of a certification report can be rewritten to clarify exactly how the evaluated software is delivered to a downstream integrator. Nothing about the product changed; the description of what was already evaluated got more precise.
New supporting documents added to the evaluation set. A vendor publishes additional guidance, such as a coding-guidance document for an evaluated library, and the certification record is updated to reference it. The product is the same. The body of guidance a user is expected to follow grew.
Validity extensions, often bundled with other updates. A certificate’s expiry date moves out by a year. In the same publication, scheme documents and developer guidance are silently refreshed. The product remains certified, but the documentation surface around it is not the one a user studied at issuance.
And then there are the changes that matter most:
Substantive additions to the Security Target. An ST gets a new compliance claim against a NIT technical decision, with corresponding evaluator acknowledgement. The functional claims a buyer is relying on are not the same as they were on day one.
Updates that arguably warrant re-evaluation. A small number of changes that we have seen are large enough that we have asked, internally, whether the original evaluation envelope still covers what the document now describes. We do not adjudicate that question publicly. We do flag the change, classify it, and make sure it is visible to anyone who cares.
Why this matters
If your supply chain depends on a Common Criteria, EUCC, SESIP, or PSA certificate, the certificate is a snapshot. The documents behind it are a moving record. “What has changed since the cert was issued?” is a real question with a real answer, and in our experience the answer is rarely zero.
Since we started monitoring, we have catalogued 23 post-issuance document changes across the schemes we cover. The interesting part is not the total; it is that every band described above shows up in normal operation, in roughly the proportions you would expect from a system where post-issuance change is treated as routine but not always loudly announced.
What we do about it
For every document we track, we record the version, the hash, and a classification of how significant the change is. Followers of a product are notified when a new version is published. Material changes, the ones at the high end of the spectrum, are flagged for broader broadcast. Nothing about this is novel; the certifying bodies do publish their updates. It is just that nobody is sitting and watching all of them at once. We are.
If you operate a product that depends on a certified component, or you are a lab, or you are a regulator, and you want to know what is actually changing in the corpus you depend on, that is what we are for.
See also
- How to Read a Common Criteria Certificate - what each section of the certificate and report is actually telling you.
- Common Criteria Certification Process Explained - how a certification gets issued in the first place.
- Common Criteria Certificate Validity - how long a certificate remains valid and what causes it to lapse.
- What is Common Criteria? - a starting point if you are new to CC.