Skip to content
Nenkin

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

Frequently asked questions

What changes after a Common Criteria certificate is issued?
A range of post-issuance changes happen routinely: PDF metadata or producer-string updates that change the file hash without changing content, editorial corrections (typos, lab name spellings, footer dates), clarifications to existing report wording, new supporting documents added to the evaluation set, validity extensions, and substantive Security Target additions such as new compliance claims against NIT technical decisions.
Do certified products stay the same after the certificate is issued?
Often yes, but not always. The certificate freezes a snapshot, but the documents behind it continue to move. Editorial corrections and clarifications are common. New supporting guidance (for example, a coding-guidance document for an evaluated library) can be added to the evaluation set. Validity extensions are sometimes bundled with documentation refreshes that change the body of guidance a user is expected to follow.
Can a Common Criteria certificate be updated without re-evaluation?
Yes, through maintenance procedures supported by most schemes. Minor changes (bug fixes, configuration updates, cosmetic document edits) can be processed as maintenance updates that leave the underlying assurance intact. Major product changes (new features, architecture changes, new platforms) typically require a new evaluation, though some schemes offer assurance continuity to reuse prior evaluation work.
How can I tell if a certified product's documents have changed?
Hash every PDF version on issuance and compare against later publications. NenkinTracker monitors every document version across SESIP, CCRA, EUCC, EMVCo, PSA, ESA, and MIFARE; we record the version, the SHA-256 hash, and a classification of how significant each change is. Followers of a product are notified when a new version is published, with material changes flagged for broader broadcast.
Does a vendor have to disclose post-certification document changes?
Certifying bodies do publish their updates, but they are not always loudly announced and the cadence varies by scheme. Changes are typically posted on the scheme's registry; whether the vendor proactively informs customers depends on the vendor and the change type. If you depend on a certified component, monitor the issuing scheme's registry or use a third-party tracker rather than relying on vendor disclosure.
Can a Common Criteria certificate be invalidated by post-issuance changes?
Yes, in the strict sense. If a substantive change to the Security Target or supporting documents is large enough that the original evaluation envelope no longer covers what the document describes, the question of whether the certificate still applies is real. Schemes do not always adjudicate this publicly. Tracking the changes and classifying them is the practical first step.