Security certification is a snapshot, and buyers read too much into it

A certificate is a moment, not a promise

A security certificate says a product passed certain tests on a certain day. It doesn't say the product will stay secure, or that the vendor will fix what breaks later.

Mariia Bakhtina, a researcher at Masaryk University's Centre for Research on Cryptography and Security, has looked at what happens after certification ^[1]. Her team studied 4,218 products certified under Common Criteria and FIPS-140, two widely used security standards. They found that 60% of all publicly reported vulnerabilities in those products were disclosed after the certificate was issued ^[1].

That's not a failing of the standards. It's what you would expect. A certificate is like a health check: it tells you the patient was well on the day of the exam. It says nothing about next year.

The problem is that buyers read certificates as if they were guarantees. They aren't. They are starting points.

What certification actually tests

Common Criteria and FIPS-140 are rigorous. They test whether a product meets specific security requirements, as described in a document called a Security Target or a Security Policy ^[2]. The tests are done by accredited labs, and the process can take months.

But the tests are done on a snapshot. The lab examines a particular version of the product, in a particular configuration, at a particular time. If the vendor updates the software a week later, the certificate still says what it said before: that version X passed the tests ^[2].

Some updates invalidate the certificate. Others don't, depending on what changed and whether the vendor re-tests ^[2]. Either way, the certificate doesn't track what happens next.

Vulnerabilities don't wait for re-certification

Bakhtina's research shows that most vulnerabilities in certified products turn up after the certificate is issued ^[1]. That makes sense. Software changes. Attackers find new ways in. A test done in 2023 doesn't catch a flaw discovered in 2025.

The study also found that the median time between certification and the disclosure of the first vulnerability was just over two years for Common Criteria products, and around 18 months for FIPS-140 ^[1]. Some products went years without a reported issue. Others had problems within months.

The takeaway is that a certificate tells you the product was built with security in mind. It doesn't tell you how the vendor handles what comes after.

What this means for you

If you buy software or hardware based on a security certificate, treat the certificate as the beginning of a conversation, not the end of one.

Ask the vendor:

• How do you handle vulnerabilities found after certification?
• How quickly do you patch, and how do you tell customers?
• Can you show which version of the software is running on my systems, and when it was deployed?
• Do you keep logs of updates and incidents, and can you prove they haven't been altered?

Those questions matter more than the certificate itself. A vendor with a strong answer to each is a vendor you can work with when something goes wrong.

A digital witness for software versions

One specific question is whether the vendor can show which version of their product was running on a given day. That can matter during an incident, an audit or a dispute.

Here, the thing to seal is each release: the build fingerprint, release notes, test results and the date. When the software is deployed, seal a deployment record linking the version to the system it ran on and the time it went live. The software itself stays on your servers. Only a fingerprint goes to WitniumChain.

Later, if someone asks which version ran on 14 March, you calculate the fingerprint of that release again. If it matches the sealed one, the release is unchanged. Change one line of code and the fingerprints won't match.

Anyone you share the release with—auditors, incident responders, customers—can check it themselves, without having to trust you or us.

A digital witness shows that a particular version existed at a particular time, unchanged since then. It doesn't show that the version was free of defects, or that it was the version the vendor should have been running. It just makes the question of which version ran a short conversation rather than a long one.

How it would work

1. At each release, seal the build fingerprint, release notes and test results.
2. At deployment, seal a record linking the version to the system and the timestamp.
3. When questioned, recalculate the fingerprint and compare it with the sealed one.

What to watch

Under the Cyber Resilience Act, manufacturers of products with digital elements must report actively exploited vulnerabilities and serious incidents within tight deadlines, from 11 September 2026 ^[3]. From 11 December 2027, such products must meet baseline security requirements, including the ability to log and monitor security events ^[4].

Those rules don't replace certifications, but they do ask vendors to show how they handle security over time, not just on the day of testing.

Bakhtina's research is a reminder that a certificate is a moment. What comes after is what counts.

Sources

1. "Security certification is a snapshot, not a guarantee", Mariia Bakhtina interviewed by Zeljka Zorz, Help Net Security, 6 November 2026, https://www.helpnetsecurity.com/2026/11/06/mariia-bakhtina-masaryk-university-security-certification/
2. Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Version 3.1, Revision 5, April 2017, Common Criteria Recognition Arrangement, https://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R5.pdf
3. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), Article 14, Official Journal of the European Union, 20 November 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj
4. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), Annex I, Official Journal of the European Union, 20 November 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj