Securing Physical Access Control
Auditable silicon root of trust for smart access and edge security

ContentWise builds its WiseACS access terminals on TROPIC01, so credentials are generated and used inside a secure element your own engineers can review.

“When you are building an access system, it is absolutely critical that you store the secrets in a very reliable way, and that there is no possibility for an attacker to access them. That is why we chose TROPIC01.”
Inside WiseACS: TROPIC01 as the root of trust at the access terminal
Where the exposure is
Access terminals sit in unsupervised, physically reachable places. Master credentials, NFC keys and identity tokens are commonly held in host soft-memory, which puts them within reach of bus probing, signal interception and side-channel extraction at the terminal itself. The practical consequences are credential cloning, unauthorised lock actuation and rogue firmware.
The verification gap
Most secure elements are supplied under NDA, which limits how far an integrator can independently review the cryptographic implementation they are relying on. The security argument of using these components has to be taken on trust rather than demonstrated.
What ContentWise built
The WiseACS platform uses TROPIC01 as its hardware root of trust. Keys are generated on-chip, Ed25519 authentication executes on-chip, the host-to-secure-element link is encrypted, and access logs leave the terminal signed. The host MCU never holds the private key.

What integration actually looks like
Adoption viability
Integrated in a shipping ContentWise platform: WiseScan terminal, WiseTag badge, WiseCloud management.
Connects to a low-cost host MCU over standard SPI — no dedicated security processor, no exotic bus.
Firmware development can start before hardware arrives — libtropic and the Python chip simulator let the host integration be written and tested against the documented command set.
The secure element doubles as a FIDO2 hardware key for workforce web authentication.
Risk mitigation
Keys generated and used on-chip; private keys are not exposed to host firmware.
Host-to-secure-element session encrypted using the Noise protocol framework.
MAC-and-Destroy PIN enforces brute-force limits in hardware rather than in software policy.
Active shield and environmental glitch detectors, designed to resist physical and fault-injection attack on the terminal.
Access logs signed at the point of generation, so downstream systems can check origin.
Public documentation and repository available for review.
What the secure element does
Auditable root of trust
The architecture and cryptographic implementations are documented publicly, so your engineers can review what the part does rather than accept a datasheet claim. Useful when you need to show your working to a certification body.
Hardware-bound device identity
A physical unclonable function derives the device identity from silicon characteristics, backed by OTP. Identity cannot be copied to a second board, which is what makes counterfeit terminal insertion hard.
Signing off the host CPU
The host MCU offloads token verification to TROPIC01, which executes Ed25519 authentication inside isolated hardware. Compromising host firmware does not yield the key.
Protected physical interface
The host link is encrypted with the Noise protocol framework, and active shields plus environmental glitch detectors are designed to resist probing and fault injection at the terminal.
Compliance readiness
Hardware-backed key storage, secure boot support and on-chip key isolation give you the technical basis for ETSI EN 303 645 work and for FIDO2 / WebAuthn.
.png)







