IoT buyers, regulators and chip customers increasingly ask for a security certificate, but PSA Certified levels, SESIP levels and Common Criteria assurance are often confused, and a certificate on the chip is regularly mistaken for a certificate on the device. PSA Certified (now run as PSA Certified by GlobalPlatform) and SESIP (the Security Evaluation Standard for IoT Platforms, adopted by CEN and CENELEC as EN 17927) are the two schemes most often quoted for microcontrollers, secure elements, RTOS platforms and connected devices. This guide explains what each level actually evaluates, how the two schemes connect, how composition lets a device reuse a chip's certificate, how they relate to the EU Cyber Resilience Act, and how to read a certificate before relying on it. It is for product security leads, hardware and firmware architects, and procurement teams evaluating components. It complements the Embedded Device Security Guide, which covers the engineering controls themselves. Scheme details were checked on the scheme owners' pages on 27 October 2026.
Key takeaways
- PSA Certified Level 1 is a reviewed questionnaire, not a test. Every level above it adds lab vulnerability assessment of the PSA Root of Trust: about 25 lab days at Level 2 (software attacks) and about 35 at Level 3 (adds physical and side-channel attacks).
- SESIP is the evaluation methodology, PSA Certified is a scheme that can use it. PSA Certified Levels 2 and 3 can be evaluated against either a lighter CSPN-style profile or a GlobalPlatform SESIP profile, with the same certificate either way.
- SESIP levels rise from self-assessment to white-box testing. SESIP1 is self-assessed, SESIP2 adds black-box penetration testing, SESIP3 adds time-limited source review, and SESIP4 and SESIP5 cover high assurance, originally through reuse of Common Criteria or EUCC results.
- Composition is the main benefit. A device maker can build on a certified chip or RTOS platform and evaluate only what it adds, but only if it stays inside the assumptions and guidance of the component certificate.
- Neither scheme is, on its own, a Cyber Resilience Act conformity route. The CRA gives presumption of conformity through harmonised standards, common specifications or European cybersecurity certification schemes such as EUCC; PSA and SESIP evidence supports that work but does not replace it.
What the two schemes are
- PSA Certified: a security framework and certification programme for silicon, system software and devices, built around the Platform Security Model and its ten security goals. The site now identifies it as "PSA Certified by GlobalPlatform". Its centre of gravity is the PSA Root of Trust (PSA-RoT): the chip and firmware that provide secure boot, secure storage, cryptographic services and attestation.
- SESIP: a GlobalPlatform certification methodology and scheme for IoT platforms, based on Common Criteria (ISO/IEC 15408) but simplified for connected products. It provides a catalogue of security functional requirements, five assurance levels, and SESIP Profiles that set minimum requirements for a product type and map them to threats. CEN and CENELEC have published it as the European Standard EN 17927.
- Common thread: both rely on accredited evaluation labs and a certification body, and both are designed to let components be certified once and reused across markets rather than re-evaluated for every customer and regulation.
PSA Certified levels
| Level | Who it is for | What is evaluated | Lab activity |
|---|---|---|---|
| Level 1 | Chip, system software and device vendors | Security best practice through a 50-question assessment: authentication and passwords, configuration, crypto, hardening, logging, privacy, secure storage, update | Lab reviews the questionnaire and evidence; no vulnerability testing |
| Level 2 | Chip vendors | PSA-RoT resistance to scalable software attacks: nine security functional requirements covering seven threats in the PSA-RoT Protection Profile | About 25 days of white-box evaluation, vulnerability analysis and penetration testing |
| Level 2 + Secure Element | Chip vendors with an SE | Adds recognition of substantial physical protection for keys and crypto operations | Add-on to Level 2 |
| Level 3 | Chip vendors | PSA-RoT resistance to substantial hardware and software attacks, including physical and side-channel threats | About 35 days of white-box evaluation |
| Level 3 + Secure Element | Chip vendors with an SE | Adds recognition of substantial physical protection for keys and crypto | Add-on to Level 3 |
| Level 4 iSE/SE | Chip vendors with an integrated secure enclave or external secure element | High robustness to physical and software attacks | Lab vulnerability assessment |
| Level 2 or 3 RoT Component | IP component vendors | A subset of the PSA-RoT security functional requirements | Lab evaluation using SESIP profiles at Level 3 |
Two points are easy to miss. First, the Level 1 questionnaire (version 2.0 onwards) is mapped to ETSI EN 303 645, NIST IR 8259A and California SB-327, which is why device makers use it as a baseline for consumer IoT rules; see the ETSI EN 303 645 Consumer IoT Guide and the NIST IR 8259 IoT Baseline Guide. Second, PSA Certified Functional API Certification is a compatibility badge, not a security evaluation: it shows the Crypto and Secure Storage APIs (and optionally Attestation and Firmware Update) conform to the specifications, tested with the psa-arch-tests suites. Chips running Trusted Firmware-M are treated as compliant because TF-M is the reference implementation.
SESIP assurance levels
| SESIP level | Evaluation activity | Assurance | Typical use |
|---|---|---|---|
| SESIP1 | Self-assessment; evaluators do not independently verify the security functions | Basic | Low-risk products, first step for a platform |
| SESIP2 | Black-box penetration testing without developer cooperation | Moderate | Closed-source platforms; general IoT components |
| SESIP3 | White-box vulnerability analysis: time-limited source code review plus time-limited penetration testing | Substantial | Roots of trust, RTOS and secure boot components in higher-risk products |
| SESIP4 | Originally reuse of SOG-IS or EUCC certified platforms through licensed labs; EN 17927 adds a SESIP-only method | High | Secure elements and high-assurance chips |
| SESIP5 | As SESIP4, at the highest level; SESIP-only route possible under EN 17927 | Highest | Payment-grade or government-grade secure hardware |
The level descriptions above follow the summary published by TrustCB, a SESIP certification body, which also states that its SESIP certificates are valid for five years from the evaluation technical report. Other certification bodies may set different validity periods, so check the certificate itself. Every SESIP certificate is only as meaningful as its Security Target: the document that lists the claimed security functional requirements, the assumptions and the scope. Read it before reading the level.
How PSA Certified and SESIP fit together
- Two routes, one certificate: PSA Certified Level 2 and Level 3 evaluations can use either an informal CSPN-inspired protection profile or a formal GlobalPlatform SESIP profile. PSA Certified describes them as delivering equivalent assurance and the same certificate. Choose the SESIP route if the result will feed a larger composed certification; the lighter route is simpler for a first evaluation.
- Shared profiles: PSA Certified and GlobalPlatform have published commonly used sets of SESIP functionality as SESIP Profiles, so a PSA-RoT evaluated under SESIP produces evidence other SESIP evaluations can consume.
- Nesting: a Level 3 RoT can include a subsystem certified at PSA Certified Level 4 iSE/SE, and the Level 3 RoT Component option uses SESIP profiles.
- Same labs, different scopes: many labs are licensed for both, but a lab's PSA licence does not imply a SESIP licence. Use the scheme owners' lab lists.
Composition: from chip certificate to device claim
Composition is where most of the value, and most of the misunderstanding, sits. A device built on a PSA Certified Level 2 chip is not itself PSA Certified Level 2. The chip certificate covers the root of trust under stated assumptions; the device maker is responsible for everything above it.
| Layer | Typical certificate | What the device maker still owns |
|---|---|---|
| Silicon and PSA-RoT | PSA Certified Level 2 or 3, SESIP2 or SESIP3 on a SESIP profile | Following the chip's security guidance: lifecycle states, debug lock, key provisioning, fuse settings |
| Secure element | Level 2/3 + SE, Level 4 iSE/SE, SESIP4/5, Common Criteria or EUCC | Correct use of the SE for keys; personalisation process |
| RTOS and secure firmware | SESIP on the platform, PSA Functional API compliance | Configuration as certified, update policy, patching the RTOS in the field |
| Device and application | PSA Certified Level 1, SESIP on the device, EN 303 645 assessment | Application code, cloud interfaces, default credentials, vulnerability handling |
See the Hardware Root of Trust Guide and the RTOS Security Guide for what the root of trust and platform layers should provide.
Regulation and procurement: where the certificates help
- EU Cyber Resilience Act: the CRA (Regulation (EU) 2024/2847, in force since 10 December 2024) gives presumption of conformity to products meeting harmonised standards, Commission common specifications, or certification under European cybersecurity certification schemes. Its recitals point to the EUCC scheme for hardware such as hardware security modules and microprocessors. GlobalPlatform lists the CRA among the regulations SESIP helps with, but treat PSA and SESIP results as supporting evidence for your technical documentation and risk assessment unless and until they are formally recognised as a conformity route. See the EU CRA Product Classes Guide and the EU Cybersecurity Certification EUCC Guide.
- Consumer IoT baselines: the Level 1 mapping to EN 303 645 and NIST IR 8259A helps answer UK PSTI, US Cyber Trust Mark and retailer questionnaires, but each regime has its own conformity process. See the UK PSTI Act Product Security Guide.
- Industrial products: for industrial automation components, IEC 62443-4-1 and 4-2 are the expected product standards; a PSA or SESIP chip certificate supports a 4-2 claim for hardware security but does not replace it. See the IEC 62443-4-1 and 4-2 Secure Product Development Guide.
- High-assurance buyers: government and payment buyers usually expect Common Criteria or EUCC at defined assurance levels. See the Common Criteria Evaluation Guide.
Choosing a level
- Low-cost consumer devices with no sensitive keys: PSA Certified Level 1 on the device, built on a chip with at least Level 1, is often proportionate.
- Devices holding cloud credentials or unique identities at scale: choose a chip with PSA Certified Level 2 or SESIP2 or above on the root of trust, because scalable remote software attacks are the main threat.
- Devices an attacker can physically own (meters, locks, payment terminals, vehicles): require Level 3, a secure element, or SESIP3 and above, because physical, side-channel and fault attacks are in scope.
- Platform vendors (RTOS, secure firmware, modules): choose SESIP on a published profile so customers can compose your evidence into their own evaluations.
- Small vendors: start with Level 1 on a certified chip and a recognised RTOS; spend the lab budget on the component that holds your keys. Large vendors should standardise on a small set of certified chips across product lines so evidence is reused.
Running a certification programme
- Decide the claim: write down which product, which layer and which level you will claim, and which customer or regulator needs it.
- Select certified components: check the certified products lists for the exact chip part number, firmware version and level, and download the security guidance documents.
- Gap assessment: run the PSA Certified Level 1 questionnaire or the relevant SESIP Profile internally first, and fix gaps such as default passwords, missing update authentication and open debug ports.
- Write the Security Target: keep the scope tight and the assumptions realistic; overreaching assumptions are the main reason certificates mean less than they appear to.
- Engage a licensed lab: labs set their own prices, so get several quotes; plan for the fixed lab effort plus your own preparation and fix time.
- Fix and retest: treat lab findings as product defects with owners and deadlines.
- Maintain: track certificate validity, re-evaluate after significant changes, and keep the vulnerability handling process active. A certificate does not cover firmware you ship next year. See the PSIRT Guide.
Measuring the programme
- Coverage: percentage of shipping products whose root of trust component holds a current PSA Certified Level 2+ or SESIP2+ certificate.
- Guidance conformance: percentage of products passing an internal check against the component vendor's security guidance (debug lock, lifecycle state, key injection).
- Certificate currency: number of certificates expiring in the next 12 months without a renewal plan.
- Drift: number of field firmware versions running outside the certified configuration.
- Lab findings: open findings from evaluations and median days to close.
Common failure patterns
- Claiming the chip's level for the device: marketing or tender responses state "PSA Certified Level 2" for a product when only the chip holds it.
- Ignoring component guidance: the device leaves the chip in a development lifecycle state or with debug open, voiding the assumptions the certificate relied on.
- Reading the level, not the Security Target: a SESIP3 certificate with a narrow scope can say less about your use case than a SESIP2 certificate with the right one.
- Confusing API compliance with security: a Functional API badge proves compatibility, not resistance to attack.
- Treating certification as a one-off: firmware changes, new vulnerabilities and expired certificates are not reflected in a certificate issued years earlier.
- Assuming regulatory equivalence: using a PSA or SESIP certificate as if it were a CRA, PSTI or Cyber Trust Mark conformity decision.
Framework mapping
| Programme activity | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Selecting certified components | SA-4 Acquisition Process; SR-5 Acquisition Strategies, Tools, and Methods | GV.SC-05 |
| Independent lab evaluation | SA-11 Developer Testing and Evaluation; CA-8 Penetration Testing | ID.RA-01 |
| Component authenticity and root of trust | SR-11 Component Authenticity; SI-7 Software, Firmware, and Information Integrity | PR.PS-02 |
| Following component security guidance | SA-5 System Documentation; CM-6 Configuration Settings | PR.PS-01 |
| Supplier assurance and monitoring | SR-6 Supplier Assessments and Reviews | GV.SC-07 |
Practitioner checklist
- Record, for each product, which layer holds which certificate and at which level, with certificate IDs and expiry.
- Verify part numbers and firmware versions against the scheme's certified products list before relying on a certificate.
- Read the Security Target and component security guidance and turn every assumption into a build or manufacturing check.
- Require Level 2 or SESIP2 at minimum for components holding device identity keys, and Level 3, a secure element or SESIP3 and above where physical attack is realistic.
- Prefer SESIP profile routes for components you will compose into larger evaluations.
- Run the PSA Certified Level 1 questionnaire internally as a device baseline even if you do not certify.
- Keep regulatory conformity (CRA, PSTI, Cyber Trust Mark) as a separate workstream that uses certificates as evidence.
- Track certificate validity and re-evaluation triggers in the product security plan.
Standards and references
- GlobalPlatform: Security Evaluation Standard for IoT Platforms (SESIP)
- PSA Certified: Getting Certified
- PSA Certified: Level 1
- PSA Certified: Level 2
- PSA Certified: Level 3
- PSA Certified: Functional API Certification
- EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
- TrustCB: SESIP certification
Related NHI Mgmt Group resources: Embedded Device Security Guide · EU Cyber Resilience Act Guide · Common Criteria Evaluation Guide · IoT Device Identity with TPM and DICE Guide