*This blog has been cross-posted from the Alpha-Omega Project: *https://alpha-omega.dev/blog/securing-the-rust-project-infrastructure-with-hardware-security-keys/
AI usage disclaimer: This content was originally written by the author. A LLM tool was used as a proofreader, and he adopted grammar corrections and minor stylistic suggestions he got from it.
Hardware security keys improve engineering security by providing unphishable protection to users who need to access sensitive systems. To bring top-tier security to the Rust Project, the Rust Foundation is excited to share how we made hardware security keys the default when accessing critical infrastructure.
How we introduced hardware security keys in the Rust Project #
When we decided to adopt hardware security keys, the Rust infrastructure team realized we needed an initial evaluation, so we launched a quick discovery process comparing some hardware vendors and models, considering, among other things:
- Whether existing hardware is fully compatible with the standards we were looking for, in particular FIDO2,webauthnandPIV - Whether companionsoftware offered by the hardware vendor is open source and maintained
- How the vendor handles security advisories on its products
We identified some vendors that fulfilled these requirements, and after experimentation with different devices, we chose Yubico’s YubiKeys as the first devices to start supporting, leveraging hardware grants from Yubico’s Secure It Forward program.
During our evaluation, we reviewed all systems used in the Rust infrastructure and checked which of them support MFA with webauthn, and mapping out their mandatory rollout. We also reviewed our existing tooling, making sure that any local authentication required for infrastructure operations worked as expected with hardware keys, which revealed some opportunities to improve our cloud security policies and settings.
Internally, the Rust Foundation established a policy mandating hardware keys for all critical infrastructure access. Our infra admins and software engineers now follow this practice when operating sensitive systems, including those underpinning crates.io.
In addition, we reviewed and identified all Rust Project members with access to infrastructure, and introduced a similar policy tailored to them, regardless of current privilege levels, ensuring non-admin users follow the same best practices.
Lastly, since several Rust Project members gathered in Amsterdam in May 2026 for this year’s Rust Project All Hands, we took the opportunity to distribute hardware keys in person to all eligible people who attended. We also ran a small setup session for those unfamiliar with these devices, and further discussed additional possibilities for hardening the Rust Project.
Future Work #
Although the focus was mostly on hardening access to critical infrastructure, officially supporting security hardware keys in the Rust Project is just the beginning.
There are other initiatives we are considering, including pushing for hardware-backed SSH keys as the default for specific infrastructure operations and exploring how to leverage hardware-backed certificates in our release process.
By hardening our infrastructure today, we’re ensuring the entire Rust ecosystem remains secure, resilient, and ready for what’s next.