Secure CAN FD Microcontrollers

Frequently Asked Questions

Why does this table list only CAN FD parts?

Cryptographic frame protection needs room for an authentication tag and a freshness counter, and the classical CAN payload of eight bytes leaves almost none. CAN FD carries up to 64 bytes per frame, which is what makes authenticated and encrypted CAN traffic practical. A controller that pairs a CAN FD interface with on-chip security is therefore the natural target for the controls cataloged on this site, so the table is scoped to that combination. A part qualifies only when it has at least one CAN FD interface and at least one hardware security feature.

What counts as secure key storage?

Any on-chip mechanism that holds key material so that firmware and an attacker with debug access cannot read it back. In practice this ranges from a simple write-only or one-time-programmable key region, through immutable secure-boot root keys, to a physically unclonable function or a separate security subsystem such as an HSM or secure enclave that performs cryptographic operations without ever exposing the key. The table marks the feature as present when the datasheet documents such a mechanism; the note names which kind.

Does listing a part imply a recommendation?

No. The table is a neutral orientation aid compiled from public product pages and datasheets. It records what the silicon offers, not a judgment of fitness for any particular design, and inclusion is not an endorsement. EmSA has no commercial relationship with the manufacturers listed. Confirm every specification against the current datasheet before making a selection, because vendors revise part lineups and feature sets over time.