PSA Certified: Arm-led IoT security baseline

Author Hugues Orgitello Last updated 27 May 2026 ~15 min read

Guide · PSA Certified

Launched in 2017 by Arm together with Brightsight, CAICT, Prove&Run, Riscure and TrustCB, PSA Certified has become within a few years the most visible IoT security reference on the silicon side, in particular for Arm Cortex-M and Cortex-A architectures. The programme combines an architectural framework (Platform Security Architecture, the PSA framework) with a three-level certification scheme, applied to chips, modules, operating systems, cryptographic libraries and finished products. This guide presents the history of the scheme, its architecture (PSA-RoT, PSA Crypto API, PSA Attestation), the progression from Level 1 to Level 3, the separate Functional API Certification, the articulation with SESIP, Common Criteria, ETSI EN 303 645, NIST 8259A and the Cyber Resilience Act, and the most common pitfalls when scoping a programme.

Origin and governance of the scheme

The context in which PSA Certified was created, in 2017, was a near-total absence of a portable security baseline for low-end IoT components. Common Criteria had existed since 1999 (ISO/IEC 15408), but its cost, lead time and smart-card heritage made it impractical for a few-dollar microcontroller. GlobalPlatform was working on what would become SESIP. Arm, which already dominates the embedded-core market, took the initiative to gather a consortium of evaluators and software vendors around a reference architecture and an evaluation scheme calibrated for IoT hardware.

Six entities founded the scheme:

• Arm, publisher of the architecture and owner of the trade name.
• Brightsight (Netherlands), a long-standing Common Criteria evaluation laboratory for smart cards and secure components.
• CAICT (China), the ICT research centre affiliated with the Chinese Ministry of Industry and Information Technology.
• Prove&Run (France), publisher of secure kernels and an evaluation specialist.
• Riscure (Netherlands), a laboratory specialised in side-channel attacks and fault injection.
• TrustCB (Netherlands), an accredited certification body, which formally issues certificates on behalf of the scheme.

TrustCB plays a central role that many industry players grasp only late: it is the sole official Certification Body of the programme. Evaluation laboratories conduct the testing, but it is TrustCB that reviews the reports and publishes the certificate on the psacertified.org portal. This separation of evaluation and certification mirrors the logic of Common Criteria and SESIP, and guarantees independence of the final decision.

The programme has since 2017 grown to roughly twenty accredited laboratories across Europe, Asia and North America. The main Arm silicon vendors actively participate: NXP, STMicroelectronics, Nordic Semiconductor, Infineon, Renesas, Microchip, Silicon Labs, Texas Instruments. On the software side, Trusted Firmware-M and Trusted Firmware-A (Linaro projects) are the reference implementations of the PSA-RoT for Cortex-M and Cortex-A respectively.

The PSA framework, a reference architecture

Before discussing certification, it is essential to distinguish the PSA framework (Platform Security Architecture) from the PSA Certified programme. The framework is a set of documents published by Arm, freely consultable, which define:

• a reference architecture for an IoT product, with the concepts of PSA-RoT (Root of Trust), Application RoT, secure and non-secure partitions;
• a family of standardised APIs: PSA Crypto API, PSA Storage API (Internal Trusted Storage and Protected Storage), PSA Attestation API, PSA Firmware Update API;
• a generic threat model for IoT products, structuring risk analysis;
• a methodology, the PSA Threat Models and Security Analyses (TMSA), which produces a standardised threat analysis per product class.

The framework is neutral with respect to hardware architecture, even though it was born in the Arm ecosystem and aligns naturally with TrustZone-M (Cortex-M) and TrustZone-A (Cortex-A). RISC-V implementations exist and are progressing, notably through Trusted Firmware-M which supports several platforms.

PSA Certified is the programme that assesses conformity of an implementation to that framework. The distinction matters in practice: a manufacturer may implement PSA without certifying (for example for an early product version), but cannot certify without having implemented the framework.

The PSA-RoT and secure / non-secure isolation

The PSA Root of Trust (PSA-RoT) is the central concept of the framework. It refers to the minimal set of hardware and software components anchoring a product's trust chain:

• Hardware Unique Key (HUK), a per-chip unique key stored in a non-extractable area;
• Initial Attestation Key (IAK), the attestation key used to sign integrity reports;
• Secure Boot, a startup chain with signature verification at each stage;
• Secure Storage, encrypted and integrity-protected storage for secrets;
• Crypto Services, cryptographic services accessible through PSA Crypto API;
• Attestation Service, generating signed attestation reports.

The PSA-RoT runs in the secure zone, isolated from the rest of the application (the non-secure zone). On Cortex-M, this isolation is typically delivered by TrustZone-M, which partitions memory, peripherals and execution transitions between the two worlds. On Cortex-A, isolation rests on TrustZone-A combined with a Trusted Execution Environment (TEE) such as OP-TEE.

Correct isolation between secure and non-secure is among the most frequent causes of non-conformity at Level 2 evaluation stage. Misconfiguration of Security Attribution Units (SAU) on Cortex-M, a peripheral shared between the two zones without mediation, a buffer overflow crossing the boundary: each of these defects invalidates isolation and tips a dossier into non-conformity.

The three certification levels

PSA Certified defines three assurance levels designed as a progression. The target level depends on the threat model, target market and available budget.

Criterion	Level 1	Level 2	Level 3
Nature	Governance and good practice	White-box laboratory evaluation	Laboratory evaluation with substantial attacks
Method	Self-assessed questionnaire + laboratory interview	PSA-RoT testing, software, side-channel and fault-injection attacks at entry level	Extended testing, hardened attacks, substantial effort
Coverage	10 requirements (Secure Lifecycle, Identification, Updates, etc.)	Full PSA-RoT against Protection Profile	PSA-RoT hardened against capable attacker
Attacker resistance	Not quantified	Basic to medium attacker	Medium to substantial attacker
Manufacturer effort	Weeks of documentation	Several months, possible analysis rounds	Longer, depends on component maturity
SESIP alignment	Indicative	SESIP3	SESIP4 and SESIP5
External reference	ETSI EN 303 645, NIST 8259A	PSA Protection Profile + SESIP cartography	Hardened PSA Protection Profile
Typical target	Finished product, OS, library	Chip, module, secure OS	High-end secure component

Level 1, governance and good practice

Level 1 is a manufacturer self-assessment against ten requirements covering governance and security hygiene: product lifecycle, unique device identification, default passwords, vulnerability disclosure, secure updates, secret storage, isolation, communication, personal data, default configuration. The questionnaire is filled in by the manufacturer then reviewed by an accredited laboratory through an interview and documentary analysis (without laboratory testing in the strict sense).

The substance of Level 1 is largely aligned with ETSI EN 303 645 and NIST 8259A: the same themes appear, sometimes in the same wording. A manufacturer that has already built a 303 645 dossier or a NISTIR 8425 self-assessment will find most of the answers to the L1 questionnaire ready to hand.

The classic pitfall is to assume that an L1 obtained on a platform is sufficient for a finished product integrating it. It is not: evaluation is specific to a combination of hardware + firmware + version, and any substantial change requires a certificate update.

Level 2, white-box laboratory evaluation

Level 2 introduces an actual laboratory evaluation on the PSA-RoT, conducted by an accredited laboratory against a published Protection Profile. The evaluation runs in white box: the manufacturer provides sources, architecture documentation, hardware schematics and relevant masks. The evaluator tests:

• conformity to the Protection Profile requirements (architecture, services, APIs);
• robustness against software attacks at entry level (overflows, argument manipulation, type confusion);
• robustness against side-channel attacks at entry level (power analysis, electromagnetic-emission analysis) on sensitive cryptographic operations;
• robustness against fault injection at entry level (clock disturbances, voltage glitches) on critical paths.

The "entry level" qualifier matters: Level 2 does not claim resistance against an attacker with substantial resources. It validates resistance to an attacker with accessible tooling, without advanced laboratory equipment. This resistance is sufficient for a wide range of consumer and industrial IoT products, but not suitable for high-value targets (payments, identity, critical infrastructure).

Level 2 is aligned with SESIP3 through a cartography jointly published by both schemes. A product certified PSA Certified L2 can in most cases be recognised as SESIP3-equivalent without a full re-evaluation (subject to TrustCB review).

Level 3, substantial attacks and laboratory effort

Level 3 extends Level 2 with substantial hardening of the attack effort. The laboratory dedicates significantly more test effort, calibrated to test resistance against a capable attacker. The attack categories are the same (software, side-channel, fault injection) but the intensity and creativity of testing are increased. The scheme does not publish a rigid hour count: duration depends on the Protection Profile applied and the complexity of the component.

Level 3 mainly targets high-end components (integrated secure elements, secure enclaves, secure microcontrollers) for applications with high security demand: payment, digital identity, e-health, certain critical industrial uses. For these targets, Level 3 maps onto SESIP4 or SESIP5, and starts to overlap with the historical Common Criteria EAL4+ to EAL5 territory.

PSA Functional API Certification

Separate from platform certification, PSA Functional API Certification validates conformity of a software implementation to the functional APIs published by Arm. It does not address overall product security, but the respect of signatures, error codes and behaviours specified by the PSA API documents.

Dimension	PSA Functional API Certification	PSA Certified L1/L2/L3
Object	Conformity to a published API (signatures, codes, behaviour)	Implementation and product security
Typical target	OS, cryptographic library, Trusted Firmware, runtime	Chip, module, finished product
APIs covered	Crypto, Storage (ITS and PS), Attestation, Firmware Update	All of these, plus architecture and attack tests
Tests	Conformity test suite (PSA API Tests)	Threat analysis, attack tests (L2/L3)
Independence	Independent of the three levels	Independent of Functional API Cert
Reference implementation	Mbed TLS for the Crypto API	Trusted Firmware-M, Trusted Firmware-A

A cryptographic library can be Functional API certified without a product integrating it being PSA Certified. Conversely, a chip certified PSA L2 is not automatically Functional API Certified; that requires a separate path. This separation avoids the classic confusion between interface conformity and security conformity.

The PSA Crypto API has, since 2020, been adopted as the cryptographic interface of Mbed TLS (now Mbed TLS Crypto, merged with PSA), making it one of the most widely deployed cryptographic APIs in embedded IoT, well beyond the PSA Certified ecosystem itself.

PSA Attestation, proof of identity and integrity

PSA Attestation is the service that produces an attestation report signed by the PSA-RoT, attesting to the hardware identity and integrity state of the product at a given instant. The report typically contains:

• the unique component identifier (Instance ID derived from the HUK);
• the hash of the firmware currently running;
• the PSA certification level reached (PSA Lifecycle claim);
• product-specific business claims;
• the signature by the Initial Attestation Key (IAK).

This report can be verified by a remote service (cloud, fleet management platform) that ensures the device it is provisioning is indeed who it claims to be, and that it runs a known firmware. PSA Attestation is used in practice for device onboarding (FDO, Microsoft IoT Hub, AWS IoT Core), key rotation and update verification.

Attestation is a PSA-RoT service, therefore protected in the secure zone. Its quality depends directly on the quality of isolation: a non-secure compromise must not enable forging an attestation report.

PSA Certified Lite for constrained MCUs

PSA Certified Lite is a Level 1 variant adapted to microcontrollers with very limited resources, where implementing a full PSA-RoT with TrustZone-M is not realistic. The scheme adapts the questionnaire to hardware constraints (no isolation unit, reduced memory), while preserving governance controls: updates, vulnerability disclosure, product support, identification.

This variant responds to an industrial reality: a substantial share of the global IoT installed base relies on 8 or 16-bit MCUs, or on Cortex-M0+ without MPU or TrustZone-M. Imposing a full PSA-RoT on these targets would be unrealistic, while granting a complete exemption would create a critical grey zone for ecosystem security. Lite formalises a compromise.

PSA Certified, SESIP and Common Criteria

The three schemes coexist and partly overlap. The table below summarises their positioning.

Dimension	PSA Certified	SESIP	Common Criteria (ISO/IEC 15408)
Publisher	Arm + consortium, TrustCB for certification	GlobalPlatform	ISO/IEC, national schemes (ANSSI, BSI, NIAP, etc.)
Date of creation	2017	2020 (first version), revisions since	1999 (ISO 15408), origin 1990 (Orange Book, ITSEC, CTCPEC)
Target	Embedded IoT, Arm Cortex-M / Cortex-A	IoT and embedded platforms, architecture-neutral	All ICT products, historical focus on smart cards and secure OS
Levels	3 levels + Functional API + Lite	5 levels (SESIP1 to SESIP5)	7 assurance levels (EAL1 to EAL7)
Assurance model	Dedicated Protection Profile per level	Modular Protection Profiles and claims	Per-product Protection Profile and Security Target
International recognition	Growing, especially in the Arm ecosystem	Growing, EU-CC recognition in preparation	Wide, CCRA recognition for EAL1 to EAL2 and SOG-IS for higher levels
Typical cost	Moderate to substantial depending on level	Moderate to substantial depending on level	High, especially above EAL4+
Regulatory recognition	Indirect (cartographies, citations)	Indirect, growing	Direct for some national schemes (payment, identity)

The practical logic is the following: for a mass-market IoT product on Arm Cortex-M, PSA Certified L1 then L2 is generally the most direct path, with a SESIP3 cartography obtained as a side effect. For a high-end secure component with strong regulatory requirements (payment, identity, eIDAS), Common Criteria remains the historical route, possibly combined with PSA Certified L3 or SESIP4/5. For a multi-architecture product (including RISC-V or Arm), SESIP offers slightly better portability.

Articulation with ETSI EN 303 645, RED 3.3 and NIST 8259A

PSA Certified L1 directly reuses the governance requirements of ETSI EN 303 645 and NIST 8259A. A manufacturer that has produced a 303 645 self-assessment dossier already holds most of the answers to the L1 questionnaire.

On the European regulatory side, the RED article 3.3 regime, applicable since 1 August 2025, mandates conformity to three essential requirements (3.3(d) network protection, 3.3(e) personal data protection, 3.3(f) fraud protection) for any internet-connected radio equipment. The formal route to presumption of conformity passes through the EN 18031 series of harmonised standards, not through PSA Certified. A PSA L1 or L2 certificate can still be cited in the technical file under article 3.3, as supporting evidence or state-of-the-art demonstration. It does not by itself open presumption of conformity.

On the United States side, NISTIR 8425 (Recommended Cybersecurity Requirements for Consumer-Grade Routers, 2022) and the US Cyber Trust Mark adopt a security capability logic close to PSA L1. Here again, PSA Certified is not the formal path to the label, but it covers a substantial part of the requirements.

Articulation with the Cyber Resilience Act

The Cyber Resilience Act, applicable from 11 December 2027, will extend cybersecurity obligations to all products with digital elements placed on the European market, radio or not. CRA harmonised standards are being drafted under a standardisation mandate from the European Commission to the European Standardisation Organisations.

Several product categories will be classed important (Class I) or critical (Class II) with mandatory third-party assessment regimes. For those categories, PSA Certified L2 or L3, or an equivalent SESIP certificate, is likely to be recognised as a means of demonstrating conformity, subject to publication of harmonised standards and the related delegated acts. The precise cartography remains to be established.

In the short term, the reasonable position is not to treat PSA Certified as an alternative route to the CRA, but as a durable investment, a substantial fraction of which can be re-leveraged when CRA standards are published.

Common scoping pitfalls

Confusing the PSA framework with PSA Certified

The most common engineering-side pitfall is to claim that the product "implements PSA" without engaging certification. That is technically correct (the framework is freely implementable) but commercially incorrect: no PSA Certified logo may be used, and no SESIP cartography is applicable. Marketing must respect that distinction.

Confusing PSA Functional API Certification with platform certification

A cryptographic library vendor sometimes communicates about Functional API Certification (Mbed TLS, for example) in a way suggesting that products integrating it are PSA-secure. They are not: Functional API Certification validates a software interface, not a security architecture. A product integrating a Functional-API-certified library can be wholly insecure if its architecture, isolation and lifecycle are deficient.

Targeting L1 when the buyer expects L2

On consumer markets, some buyers (distribution chains, smart home integrators) have started to demand PSA Certified L2 in their specifications, in particular for exposed components (gateways, hubs, cameras). Presenting an L1 when an L2 was expected loses contracts. Verifying the expected level upstream of the product roadmap is essential.

Neglecting secure / non-secure isolation

Isolation between PSA-RoT (secure) and application (non-secure) is the most heavily tested aspect during an L2 evaluation. A poorly configured SAU on Cortex-M, a peripheral shared without mediation, a global variable crossing the boundary: each of these defects is detected in the laboratory and invalidates the evaluation. Internal audit of isolation, with adapted tooling (reference Trusted Firmware-M), should be conducted before laboratory entry.

Underestimating laboratory iterations

An L2 evaluation without a prior internal report often produces several rounds of analysis, with firmware or hardware corrections between iterations. The schedule must allow for those rounds: aiming for L2 in six calendar weeks without prior internal pre-evaluation is generally unrealistic.

Believing L2 substitutes for a cryptographic review

Level 2 validates correct implementation of cryptographic services per the Protection Profile, but does not exhaustively cover the quality of application protocols built on top. A cryptographic review of the business protocol (typically TLS, MQTT-S, LwM2M-DTLS, proprietary protocols) remains necessary in addition.

Confusing PSA Lite with PSA L1

PSA Certified Lite is not a subset of L1; it is an adjacent programme aimed at components for which L1 cannot apply faithfully. Presenting it as a weakened L1 risks losing credibility with an informed buyer.

For a manufacturer: scoping the programme

See also

• SESIP: IoT platform security evaluation methodology
• TPM 2.0 and TCG hardware security
• Common Criteria (ISO/IEC 15408): IT security eval
• ETSI EN 303 645: cybersecurity for consumer IoT
• Cyber Resilience Act (CRA): EU baseline for digital
• IEC 62443 (ISA-99), industrial control cybersecurity

Working on scoping a PSA Certified programme for a real product? AESTECHNO can audit your design and certification plan. Get in touch →

Three steps structure a serious scoping exercise:

1. Determine the target level. Threat model, target market, buyer contractual requirements, regulatory anticipation (RED 3.3, CRA). This analysis must produce an explicit target: L1, L2, L3, Lite, or Functional API. Is a SESIP cartography also targeted? A cartography with a national label (such as the Traficom label, the UK PSTI Act, the Singapore CLS)?
2. Select the silicon platform and reference firmware. PSA Certified L2 and L3 are realistic on a chip whose silicon is itself certified (typically an Arm SecurCore or an MCU with TrustZone-M active), and on a reference Trusted Firmware-M or a maintained derivative. Starting L2 on a platform without PSA-RoT support is generally counterproductive.
3. Internal pre-evaluation before laboratory entry. Isolation testing, TMSA threat-model review, API conformity verification. This phase substantially reduces laboratory evaluation duration and the number of iterations.

For the European regulatory dimension (RED 3.3, CRA, EN 18031), see the RED pillar which details the presumption-of-conformity routes and how they articulate with voluntary certification schemes such as PSA.

Need help?

A 30-minute audit with AESTECHNO engineers.

AESTECHNO is the electronics design house that edits spilma. We help product teams scope their certification effort and avoid the common mistakes.

Book a free audit

Going further

• ETSI EN 303 645: consumer IoT cybersecurity, the baseline behind PSA Certified L1
• Cyber Resilience Act: European regulation applicable from December 2027
• RED pillar: general European radio framework and article 3.3
• Glossary: definitions for PSA-RoT, TrustZone, attestation, SESIP

Sources & references

1. PSA Certified, official portal of the certification programme , PSA Certified www.psacertified.org/
2. PSA Certified, certification levels (Level 1, 2, 3) , PSA Certified www.psacertified.org/certification/
3. Arm Platform Security Architecture, reference architectures , Arm developer.arm.com/architectures/security-architectures/platform-security-architecture
4. GlobalPlatform SESIP, evaluation methodology for IoT platforms , GlobalPlatform globalplatform.org/sesip/
5. NIST IR 8259A, IoT Device Cybersecurity Capability Core Baseline , NIST csrc.nist.gov/publications/detail/nistir/8259a/final
6. NIST IR 8425, Recommended Cybersecurity Requirements for Consumer-Grade Routers , NIST csrc.nist.gov/publications/detail/nistir/8425/final
7. ETSI EN 303 645 V3.1.3, cybersecurity for consumer IoT , ETSI www.etsi.org/deliver/etsi_en/303600_303699/303645/