Join our Newsletter — 33% off our NHI Course
Home› Guides› PSA Certified and SESIP Guide: Choosing Chip and…
Guide OT & IoT Security

PSA Certified and SESIP Guide: Choosing Chip and Device Security Certification

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 27 October 2026 13 min read
On this page

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

LevelWho it is forWhat is evaluatedLab activity
Level 1Chip, system software and device vendorsSecurity best practice through a 50-question assessment: authentication and passwords, configuration, crypto, hardening, logging, privacy, secure storage, updateLab reviews the questionnaire and evidence; no vulnerability testing
Level 2Chip vendorsPSA-RoT resistance to scalable software attacks: nine security functional requirements covering seven threats in the PSA-RoT Protection ProfileAbout 25 days of white-box evaluation, vulnerability analysis and penetration testing
Level 2 + Secure ElementChip vendors with an SEAdds recognition of substantial physical protection for keys and crypto operationsAdd-on to Level 2
Level 3Chip vendorsPSA-RoT resistance to substantial hardware and software attacks, including physical and side-channel threatsAbout 35 days of white-box evaluation
Level 3 + Secure ElementChip vendors with an SEAdds recognition of substantial physical protection for keys and cryptoAdd-on to Level 3
Level 4 iSE/SEChip vendors with an integrated secure enclave or external secure elementHigh robustness to physical and software attacksLab vulnerability assessment
Level 2 or 3 RoT ComponentIP component vendorsA subset of the PSA-RoT security functional requirementsLab 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 levelEvaluation activityAssuranceTypical use
SESIP1Self-assessment; evaluators do not independently verify the security functionsBasicLow-risk products, first step for a platform
SESIP2Black-box penetration testing without developer cooperationModerateClosed-source platforms; general IoT components
SESIP3White-box vulnerability analysis: time-limited source code review plus time-limited penetration testingSubstantialRoots of trust, RTOS and secure boot components in higher-risk products
SESIP4Originally reuse of SOG-IS or EUCC certified platforms through licensed labs; EN 17927 adds a SESIP-only methodHighSecure elements and high-assurance chips
SESIP5As SESIP4, at the highest level; SESIP-only route possible under EN 17927HighestPayment-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.

LayerTypical certificateWhat the device maker still owns
Silicon and PSA-RoTPSA Certified Level 2 or 3, SESIP2 or SESIP3 on a SESIP profileFollowing the chip's security guidance: lifecycle states, debug lock, key provisioning, fuse settings
Secure elementLevel 2/3 + SE, Level 4 iSE/SE, SESIP4/5, Common Criteria or EUCCCorrect use of the SE for keys; personalisation process
RTOS and secure firmwareSESIP on the platform, PSA Functional API complianceConfiguration as certified, update policy, patching the RTOS in the field
Device and applicationPSA Certified Level 1, SESIP on the device, EN 303 645 assessmentApplication 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

  1. Decide the claim: write down which product, which layer and which level you will claim, and which customer or regulator needs it.
  2. Select certified components: check the certified products lists for the exact chip part number, firmware version and level, and download the security guidance documents.
  3. 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.
  4. 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.
  5. 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.
  6. Fix and retest: treat lab findings as product defects with owners and deadlines.
  7. 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 activityNIST SP 800-53 Rev. 5NIST CSF 2.0
Selecting certified componentsSA-4 Acquisition Process; SR-5 Acquisition Strategies, Tools, and MethodsGV.SC-05
Independent lab evaluationSA-11 Developer Testing and Evaluation; CA-8 Penetration TestingID.RA-01
Component authenticity and root of trustSR-11 Component Authenticity; SI-7 Software, Firmware, and Information IntegrityPR.PS-02
Following component security guidanceSA-5 System Documentation; CM-6 Configuration SettingsPR.PS-01
Supplier assurance and monitoringSR-6 Supplier Assessments and ReviewsGV.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

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

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 27 October 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org