Lab
Where I prove what I advise.
I do not recommend what I have not tested. Since 2019 I have operated a private research laboratory to validate every position I hold on technology resilience. These are its public outputs.
Active projects
Kyber.Club
kyber.clubThe world's first public platform for generating NIST FIPS-compliant post-quantum cryptographic key pairs — ML-KEM (CRYSTALS-Kyber), ML-DSA and SLH-DSA — directly in the browser. Free of charge, no account required. Over 30,000 key pairs generated to date. Built to demonstrate that post-quantum cryptography is accessible today, not in 2035.
Hard.Email
hard.emailA hardened email server implementation that independent security evaluations consistently place at the top of any benchmark. Hard.Email demonstrates that maximum email security — SPF, DKIM, DMARC, DANE, MTA-STS, BIMI and quantum-safe transport — is achievable on commodity hardware without commercial security products. A reference implementation for organisations that want to know what good email security actually looks like.
ZTZT.dev
ztzt.devZero Trust Zero Tolerance — my implementation of a server infrastructure based on strict zero-trust principles: no implicit trust, least-privilege access everywhere, continuous verification at every layer. ZTZT.dev documents the architecture, the configuration decisions and the threat model behind a production zero-trust deployment built without proprietary security platforms. The infrastructure that hosts this website.
BeatQuantum
beatquantum.comResearch and analysis on the post-quantum transition — timelines, technology readiness, standards developments and practical implementation guidance for organisations beginning the migration. BeatQuantum synthesises my own laboratory findings with the published literature to provide a practitioner's view of where the field actually is, as distinct from where vendors and standards bodies say it will be.
Pandit.tech
pandit.techTechnology resilience notes and longer-form technical writing — implementation details, configuration guides, threat analyses and research outputs that are too specific for a general audience but too valuable to leave unpublished. For technologists, architects and security engineers who want the detail behind the recommendations.
Why I run a lab
Every recommendation I make in a board briefing, an advisory engagement or a speaking session has been tested first. I do not accept vendor assurances at face value. I do not recommend configurations I have not deployed. I do not cite timelines I have not independently validated.
This commitment to proving before speaking is the source of the phrase Prove first. Speak later. It is also why I am willing to make specific, falsifiable claims about what is achievable — about post-quantum migration timelines, about email security benchmarks, about zero-trust architectures — that many practitioners are not.
The lab is not a commercial product. It is a condition of intellectual honesty. All public outputs are free to use.