Smart cities.
When a single resident credential travels across transit, parking, library, recreation, parking-meters, and city services, the security architecture under it has to scale across a portfolio of issuers without leaking keys to anyone.
A city-wide credential, in practice
The DESFire application model fits this perfectly. One card, many applications, each with its own key set. Transit fares live in one application; library access in another; community-centre membership in a third. None of them share keys. A breach in one application does not propagate to the others.
The SAM model fits too. Different city departments can hold different SAM personalisation profiles — each owns their keys, none of them sees anyone else’s. The card is one credential the resident carries; the back office is several departments that never trust each other with their key material.
Smart-city deployments also touch the buildings inside them. The municipal HVAC, lighting, and BMS layer of a city hospital or civic centre is handled by our sibling team — the building-automation platform at AmbiAutomation — retrofitting existing VRV / VRF systems with a BACnet/MODBUS server and operator app. When the same resident card needs to badge into the building and the back-office HVAC needs hardware-rooted device identity, the two sides of the Ambimat ecosystem talk to each other.
Smart-city hardware and the EU Cyber Resilience Act
Blog: EU Cyber Resilience Act for IoT
What the CRA means for connected-hardware and smart-city manufacturers — scope, secure-by-design, lifecycle, and the 2026–2027 deadlines.
Blog: secure by design under the CRA
Why hardware-backed trust matters for smart-city and IoT deployments sited in public space.
AmbiSEC for smart city and IoT security
The hardware root of trust for city infrastructure — non-extractable identity, secure OTA, lifecycle keys.
Designing a city-wide credential program?
The hard part isn’t the cards or the readers — it’s the inter-departmental key-custody model. Talk to engineers.