Cryptography
Encryption that holds today and can be replaced tomorrow
Nobody knows which algorithm will still be safe five years from now. What you can plan for is being able to swap it out without touching the application each time.
What you get
- Your keys and certificates – one place that issues, renews, and revokes them—run as a service, not as a second data center you have to operate (PKI as a service). No more certificates expiring without anyone noticing
- Your key exchange – designed as a hybrid—classical and quantum-resistant at once—so the switch doesn't hinge on a single cutover day
- Your signatures – handled separately from transport. A signature on a contract must still be verifiable ten years from now; a session key doesn't have to be
How a replacement works
- Inventory the algorithms
- Decouple them from the application
- Run old and new side by side
- Make the new one the default
- Retire the old one
Algorithms and key lengths follow BSI TR-02102 and the NIST standards for ML-KEM and ML-DSA. Where a certified cryptographic module is required, we integrate one—the certificate itself is issued by the certification body, not by us.
BSI TR-02102 and post-quantum deadlines – where each deadline comes from, what is actually binding, and a checklist for existing applications.
Read the technical documentation – a .NET library that adds ML-DSA and ML-KEM to existing code, and a crypto service for L4Re and Windows. Both are published as previews.
Do you know which algorithms run where in your systems?
Request a crypto inventory