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:

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.
2. A product matches only when every token of its CPE name appears in the validated module’s name, with generic words (cryptographic, module, FIPS…) ignored.
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 distinctively named product. 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.

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].