The problem
Large quantum computers will break RSA and elliptic-curve cryptography. Data that is intercepted today can be decrypted later, so government organisations need to know now where they use vulnerable algorithms. Most of them have no idea: cryptography hides in libraries, config files, certificates and one-off helper functions spread over hundreds of repositories.
PQNavigator answers that question. It scans repositories without running them, builds a cryptographic inventory (a CBOM) and assesses what has to change, in which order, following the PQC Migration Handbook by AIVD, CWI and TNO.
What I do
The review interface
I build the front-end where people go through findings, risks and scan results per repository. The hard part is not the table, it is the language: a finding like "RSA-2048 key generation in a JWT signer" has to make sense to a developer and to a policy advisor.
End-to-end flows
I design and build the flows from a scan request to a finished report, across the Next.js front-end, the NestJS and FastAPI services, and the server-side jobs that process scan data.
Infrastructure
I set up and maintain the servers on Proxmox and the Kubernetes cluster the platform runs on, plus the deployment workflows and the local development setup, so the whole stack runs on a laptop the same way it runs in the cluster.
Stakeholders
I join sessions with ministries (BZK, BuZa, VWS) and VNG, and turn their feedback and constraints into concrete product changes.
Decisions and trade-offs
Accessibility is a requirement, not a nice-to-have: government software has to meet WCAG 2.2. That rules out a lot of "clever" data visualisation. Every chart needs a readable text equivalent, and colour alone never carries the meaning of a risk level.
Owning both the interface and the infrastructure means fewer handovers. When a scan is slow, I can see if the cause is the UI, the API or the cluster, instead of filing a ticket and waiting.
Where it stands
PQNavigator has reached a working proof of concept and is validated against open-source repositories from the Dutch public sector. Organisations were surprised by how many cryptographic dependencies it found, and told us they did not want another platform to run themselves. That feedback moved the product from a self-hosted tool to a managed service.
Findings from those scans also became real fixes: I turned three of them into pull requests for public-sector projects, which you can read about in the open-source case study.
The pull requests
- Open minvws/nl-mgo-dvp-proxy#8 feat(oidc): add crypto-agility + ML-DSA-65 support for client-assertion JWT +158 −56
- Open fundament-oss/fundament#424 fix(openfsc-operator): shorten group CA duration to 3 years +65 −2
- Open Amsterdam/brp-amsterdam-api#195 Add AES-256-GCM BSN encryption and opt-in post-quantum TLS to RvIG +209 −12