About this tracker

Sources

Everything on these pages is parsed from public NIST sources: the CMVP validated modules search, the per-certificate detail pages, the modules-in-process list and the implementation-under-test list. Snapshots are archived as they are taken, and every page shows the date of the snapshot it was built from, so there is never any doubt how fresh a number is.

What we derive ourselves

NIST does not publish when a certificate moved to the historical list or was revoked. This tracker diffs its own snapshots and records the date each change was first observed. Timeline entries are therefore labeled “observed on”: the change happened on or before that date, and observation began on 2026-08-21, so earlier moves carry no date at all. That derived timeline exists nowhere else, which is exactly why it is worth publishing.

What we deliberately leave out

Certificate pages on the NIST site list vendor contact people, email addresses, and phone numbers. This tracker never ingests them: vendor records here are company name and website only.

CVE matching, and its limits

Some certificate pages carry a “known CVEs in this module family” section. Those associations are heuristic and deliberately conservative, in this order:

0. Only active certificates are scanned. Historical and revoked validations are skipped, so any count of matched certificates is against the active list, not against the full corpus. This matters for reading the numbers: most certificates in the tracker were never examined for CVEs at all.
1. The vendor name must match an NVD CPE vendor exactly after normalization (a small alias table covers known renames). There is no fuzzy vendor matching: a near-miss shows nothing rather than risking someone else’s CVEs. This is also the largest single source of misses: a vendor NVD spells differently from NIST matches nothing.
2. A product matches only when every token of its CPE name appears in the validated module’s name. Generic words (cryptographic, module, FIPS…) earn no credit toward a match but must still be present, so a long specific product name cannot decay into a short generic one.
3. Operating-system CPE entries are excluded entirely. A crypto module named after its platform does not inherit the platform’s CVE history.
4. Only high-confidence pairs are published: the certificate’s own version strings must intersect a CVE’s vulnerable range, or the CVE must apply to any version of a product matched on two or more distinctive tokens. Everything weaker is kept internally and never rendered.

Even then, a match is a name-based association with the module’s product family. It is not a statement that the vulnerability lies inside the validated cryptographic boundary, and it is not a claim about the vendor. Absence of a CVE section means only that nothing cleared the bar above. Corrections are welcome and are applied through a per-certificate override list.

Corrections made

2026-09-08. Two certificates for Cisco wireless access points carried CVE-2007-1467, which is against the Cisco Wireless LAN Solution Engine, a discontinued management appliance and a different product. The matcher was dropping the words “solution” and “engine” from the CPE product name as generic, which left it matching on “wireless” and “lan” alone. Rule 2 above now requires generic words to be present even though they earn no credit, and both pairs are denied outright in the override list. The same day, the CPE dictionary fetch was found to stop at the first 10,000 entries per vendor with no paging, which silently truncated exactly the vendors holding the most certificates. That is fixed, and the scan now writes a report of what it discarded so the next gap is visible rather than inferred.

2026-09-09. Six certificates stopped showing CVEs, and that is a tightening rather than a loss. Two Cisco Adaptive Security Appliance certificates validated in 2025 and 2026 were carrying CVE-2014-3394, an eleven-year-old advisory. The product family was right, but the match came through the any-version path, which has no version evidence at all: NVD says the CVE applies to every version, so the only thing tying it to the module is the name. Over a gap that long the claim is not worth making. Rule 4 now demotes an any-version match when the CVE predates the certificate’s first validation by more than five years, which also took four Cisco Secure Firewall certificates out. A genuine version intersection is exempt, because that is real evidence rather than a name and a date.

Sunset dates

Sunset dates come from the certificate pages. Two caveats worth knowing: all remaining active FIPS 140-2 certificates share the 2026-09-21 sunset regardless of what their page said earlier, and a module operating in a bound configuration inherits the earliest sunset of the modules it binds to, so the printed date can be optimistic. When in doubt, read the caveat field on the certificate.

How it is built

A Go program fetches the NIST pages, keeps one JSON file per certificate as its state, diffs the fresh snapshot against the previous one and writes out whatever changed. Hugo turns the result into about 5,500 static pages. There is no database behind any of this and nothing runs in your browser apart from the search box on the index page. The CVE pass runs separately against the NVD so a slow NVD never holds up a refresh.

Contact

Corrections and questions: [email protected].