ETSI EN 303 645 provision 5.4-1 says sensitive security parameters in persistent storage shall be stored securely by the device. The standard names appropriate mechanisms: a Trusted Execution Environment, encrypted storage tied to the hardware, a Secure Element or Dedicated Security Component, and software running on a UICC. Plain external flash is the thing to avoid.
What counts as a sensitive parameter
Think of anything that lets someone impersonate the device or the manufacturer: private keys, device identity keys, network credentials, API tokens and encryption keys for stored data. The standard is concerned with persistent storage but notes manufacturers can apply similar approaches in memory.
The options in ETSI's list
- Trusted Execution Environment. Its example is a remote controlled door lock that uses a TEE to store and use its parameters.
- Hardware backed encrypted storage. Storage whose protection is tied to the silicon.
- Secure Element or Dedicated Security Component. A separate component designed to hold secrets.
- UICC or eUICC. For example, the standard notes root keys for cellular access stored in a UICC.
Another ETSI example describes a wireless thermostat that keeps Wi-Fi credentials in a tamper protected microcontroller rather than in external flash.
Which to choose
The right answer depends on your threat model and parts. A rough guide:
- Attacker with network access only. Make sure secrets are not exposed through the file system or debug interfaces. Encryption with a hardware bound key may be enough.
- Attacker with the device in hand. Assume they can read external flash and probe buses. Use a part with tamper protected storage, or a separate secure element.
- A key that must never leave. Prefer storage where the key can be used without being exported, so the application asks for a signature rather than reading the key.
The best fit depends on vendor data sheets and your risk assessment, and I have not compared specific parts here.
Provisioning matters as much as storage
A key that is stored well but injected through an insecure factory process is still exposed. ETSI provision 5.4-2 says a hard-coded unique per device identity used for security shall resist tampering by physical, electrical or software means. Control who can see the key at manufacture, and log what was provisioned to which unit.
Related checks
Disable debug interfaces, so a port cannot read the storage. Avoid storing secrets in source code or image files. And keep update verification keys protected, since an attacker who changes the trusted key can install anything.
Quick check
Is encrypted external flash enough?
ETSI lists storage mechanisms such as TEEs, secure elements and hardware associated encrypted storage. Whether encryption alone is enough depends on where the encryption key lives and your threat model.
Does ETSI require a secure element?
No. It lists several appropriate mechanisms, and a secure element is one of them.
Where Safeguard fits
Safeguard covers the software supply chain side of this work: SBOM and dependency scanning, policies and gates, and compliance and evidence automation. It does not replace hardware security features. A free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
