How AmbiSecure platforms get deployed.
Anonymised architecture write-ups from real engagements. Each one focuses on the deployment constraint that shaped the design — not on who the customer was. Customer names and metrics are kept private; the engineering is not.
Three deployment patterns
Passwordless workforce authentication
A 9,000-seat workforce migrating from SMS / TOTP to FIDO2 across Okta, Microsoft Entra ID, and a legacy CAS-backed application stack. Architecture for the mixed estate.
Closed-loop transit ticketing
A metro operator rolling DESFire EV2 across 700+ validators with SAM-backed offline trust, sub-300 ms tap-and-go, and zero-trust to the backend during outages.
Secure device identity for IoT
A fleet-class IoT manufacturer adding hardware-rooted identity to a connected-device line with secure-element provisioning at the SMT line and PKI lifecycle integration.
How we write these
Every case study on this page is written under the same editorial rules:
- No customer names. If you need a reference, ask — we’ll arrange a direct call under NDA.
- No fabricated metrics. Numbers in these write-ups are either architectural targets (sub-300 ms validator response, AAL3 enforcement, etc.) or design-time figures (fleet size, validator count, applet count). We do not invent post-deployment efficacy numbers.
- No fabricated logos or compliance claims. Certifications listed are the certifications of the components we shipped, not customer-side compliance posture.
- The architecture is the story. Each write-up reads as an engineering retrospective — what the constraint was, what we built, what we’d do differently.
Looking for something close to your problem that we haven’t written up yet? Ask the team directly.
Have a deployment we should add to this page?
If you’ve shipped on AmbiSecure and want the architecture written up (named or anonymised), we’ll co-author with your team.