Close Search


What are the PSA Certified 10 Security Goals?

Building a Foundation of Trust

The most common IoT hacks take place due to the simplest security measures being missed.

PSA Certified is committed to creating a foundation of trust for all connected devices and making this as easy as possible to prevent these simple IoT attacks taking place. In order to achieve this, the PSA Security Model document, containing 10 goals, was devised to guide security best practice and provide a practical checklist to follow.

PSA Certified takes a holistic view of security, considering both hardware and software security. The 10 security goals are in the DNA of PSA Certified and inform the whole security framework and evaluation scheme.

Every product has unique functional and security requirements however, these goals outline the common requirements that should be implemented into every connected device. The 10 security goals guide security design by covering the security foundations, allowing products and features to be developed on top while also providing a set of requirements the ecosystem can rely on.

Find information about the 10 security goals and how you can easily prove you have shown due diligence in your product design below.

The PSA Certified 10 Security Goals:

Unique identificationUnique Identification

To interact with a particular device, a unique identity should be assigned to the device and this identity should be attestable. This identity facilitates trusted interaction with the device for example, exchanging data and managing the device.

Security lifecycleSecurity lifecycle

Devices should support security lifecycle that depends upon software versions, run-time status, hardware configuration, status of debug ports and the product lifecycle phase. Each security state of the security lifecycle should be attestable and may impact access to the device.


Attestation is the evidence of the device’s properties, including the identity and lifecycle security state of the device. The device identification and attestation data should be part of a device verification process using a trusted third party.

Secure bootSecure boot

To ensure only authorized software can be executed on a device, secure boot and secure loading processes are required. Unauthorized boot code should be detected and prevented. If the software cannot compromise the device, unauthorized software may be allowed.

Secure updateSecure update

Secure updates are required in order to provide security or feature updates to devices. Only authentic and legitimate firmware should be updated on the device. Authentication, at the time of download, may be performed however, the execution of the update must be authorized via secure boot.


Preventing rollback to previous software versions is essential to ensure that previous versions of the code can’t be reinstated. Rollback should be possible for recovery purposes only when authorized.


Isolation aims to prevent one service from compromising other services. This is done by isolating trusted services from one another, from less trusted services and from un-trusted services.


Devices should support interaction over isolation boundaries to enable the isolated services to be functional. The interfaces must not allow the system to be compromised. It may be required to keep the data confidential. Interaction should be considered both within the device and between the device and the outside world.

Secure storageSecure storage

To prevent private data being cloned or revealed outside the trusted service or device, it must be uniquely bound to them. Confidentiality and integrity of private data is typically achieved using keys, which themselves need to be bound to the device and service.

Cryptographic/trusted services

A minimal set of trusted services and cryptographic operations should be implemented as the building blocks of a trusted device. These should support critical functions including security lifecycle, isolation, secure storage, attestation, secure boot, secure loading and binding of data.

Download our one-pager summarising the 10 security goals

Communicating your product security

PSA Certified Level 1 assessment provides assurance of adherence to security best practice and alignment to governmental regulations. The assessment questionnaire is derived from the 10 security goals along with threat models and government requirements. Upon successful completion, the certified product is assigned a unique certificate that is added to the list of certified products to communicate across the ecosystem that security best practice has been adhered to.

Next Steps

The PSA Security Model details the 10 security goals and how to achieve them.  Download the PSA Security Model.

Related Resources

Find out more about PSA Certified Level 1.

Learn more about how PSA Certified was developed.

What is an Entity Attestation Token?

Creating a Trusted Web of Devices: Entity Attestation Tokens Explained

As the number of IoT devices being integrated into our businesses and lives increase, more decisions are made on the data and insights from these devices. For informed decisions to be made, we need to trust the data, which relies on having trusted devices. This is increasingly difficult, as IoT devices are complicated – containing a lot of code and hardware that will inevitably contain security vulnerabilities.

Enabling Risk-based Judgements

PSA Certified calls for a small hardware protected region of the chip, called the PSA Root of Trust (PSA-RoT), that acts as a source of confidentiality and integrity. The PSA-RoT includes a small set of useful security functions, which are made accessible to software developers via open source and easy-to-use PSA Functional APIs. One of these key APIs deals with attestation and the creation of an Entity Attestation Token (EAT).

The Entity Attestation Token is a beautifully simple way for IoT devices to make claims about a device’s status that can be useful to OEMs and cloud service providers who want assurance that they can trust the devices. Simply explained it’s a digital report card on what the device is and how it is performing.

A Mechanism for Communicating Trust

With large amounts of fragmentation in IoT devices and software, service providers struggle to know how to identify the trustworthiness of devices they are connected to. Cloud service providers need to make informed judgements on end devices to ensure the data they are providing can be trusted. This requires a mechanism to identify, characterize and authenticate them.

EAT has the capabilities to provide this source of trust, using a cryptographically signed piece of data containing claims that are generated in the device Root of Trust (RoT). There are many ways it can be useful, but most importantly it can be read by a Relying Party (for example, the server or service). The Relying Party can verify the claims made by the device such as:

  • The unique identity of the device
  • Installed software on the device and its integrity status
  • Security assurance and certification status (such as a PSA Certified level)
  • Manufacturer of the device hardware

Using this information, the Relying Party can make informed decisions such as whether the device is legitimate and should be onboarded, or what services should be enabled based on its security credentials.

Device attestation using Entity Attestation Tokens to communicate claims about a device, enabling the Relying Party to make an informed decision.
Device attestation using Entity Attestation Tokens to communicate claims about a device, enabling the Relying Party to make an informed decision.


Easing the Implementation of EAT

Our new Entity Attestation Token white paper was co-created with the author of the EAT source code and provides you a unique insight into the technology. Download the whitepaper to learn more including:

  • The anatomy of an Entity Attestation Token
  • The four-step process of device attestation
  • Use cases
  • How the PSA Certified ecosystem is supporting its adoption.

Download Entity Attestation Token white paper

PSA Certified aims to reduce IoT fragmentation and ease security concerns across the ecosystem, which is why we’re passionate about providing open source examples for EAT, which you can find in the Trusted Firmware-M project. If you’re looking for products that support EAT, you can find them here.