PSA Certified is an independent security evaluation scheme for chips, system software and connected devices built on a PSA Root of Trust (PSA stands for Platform Security Architecture). It was founded by Arm and is now run by GlobalPlatform. Certification works in layers. The chip’s Root of Trust is assessed first, then the system software on it, then the device, and a certificate for one layer counts only if the layers below it hold their own certificates or were covered in the same evaluation. A device maker’s certification route is Level 1; Levels 2 to 4 are for chip vendors. In practice, PSA Certified IoT security is only as convincing as the secure boot and provisioning evidence you can show behind the certificate number.

TechnoLynx helps device makers map a retailer’s requirement to the closest certification scheme, and assembles the root-of-trust and secure-boot evidence behind it. That is engineering work, part of our AI engineering for IoT and embedded devices. The certificate itself comes from an evaluation laboratory’s review and the PSA Certification Body.

What PSA Certified evaluates, from chip to finished device

At the bottom of the stack is the chip’s PSA Root of Trust (PSA-RoT). It combines an Immutable Platform Root of Trust, which cannot be changed after manufacture, with an Updateable Platform Root of Trust, which can be updated securely. PSA Certified treats the PSA-RoT as the most trusted security component on the device. Its job is to provide a small set of services that everything above it depends on: cryptography, secure storage, attestation and trusted boot. A mandatory requirement is that the chip isolates the Secure Processing Environment from the Non-secure Processing Environment in hardware, for example with TrustZone or dual cores.

There are three evaluation scopes: the chip, the system software and the device. The specifications do not depend on any particular architecture or implementation, so they can be applied to any chip, software or device.

PSA Certified Levels 1 to 4 and who each one is for

Level	Who certifies at it	What the evaluation involves	Lab effort published by PSA Certified
Level 1	Chip vendors, system software vendors and device makers	About 50 security requirements split into chip, software and device sections, answered in a questionnaire that a lab reviews; each section passes with at most one answer outside the expected answer, and that one needs a rationale	Not stated
Level 2	Chip vendors	A test-lab evaluation of the PSA-RoT against a Protection Profile of nine security functions, including penetration testing; the main threat is scalable remote software attacks	25 man-days
Level 2 + Secure Element	Chip vendors	Recognises solutions that add substantial physical protection for keys and cryptographic operations	Not stated
Level 3	Chip vendors	Vulnerability analysis and penetration testing that also bring physical, side-channel and perturbation attacks into scope	35 man-days of white-box evaluation
Level 4 iSE/SE	Chip vendors using an integrated Secure Enclave or an external Secure Element	High attack resistance, including advanced fault injection and differential power analysis (EMFI, single laser, multi-glitching), with cryptography of at least 128-bit strength	Not stated

For chips, FPGAs or development systems, a pre-certification called Level 2 Ready exists. The lab tests only the security functions the vendor claims, and only logical attacks are considered. A Level 4 iSE/SE subsystem can also be composed into a Level 3+SE certification of the full PSA-RoT.

Level 4 iSE/SE is not a device-maker certification. It is for chip vendors using an integrated Secure Enclave or an external Secure Element. PSA Certified’s guidance to OEMs is that a Level 2 chip will be ideal for many IoT devices. It points to Level 3 for applications where the assets are valuable enough that they need protection from local physical and side-channel attacks such as differential power analysis and voltage glitching.

How a device gets PSA Certified at Level 1

1. The developer (chip vendor, system software vendor or device OEM) fills in the questionnaire sections that match the chosen evaluation scope.
2. The developer completes the assessment information and submits the questionnaires to an Evaluation Laboratory.
3. The lab checks that the rationale for each requirement is consistent with what the requirement says, and may ask for clarification.
4. If the lab passes the product, it issues an EAN-13, and the PSA Certification Body certifies the product and publishes the number with the product reference.
5. The final certificate number has 18 digits (EAN-13+5). The extra five digits record the number of certification attempts and the software version, and the attempt digit goes up on a delta certification.

If we use a PSA Certified chip, is the finished device certified?

No. The device still needs its own Level 1 evaluation. That evaluation is performed on one specific system software and chip combination, and the device certificate is valid for that combination only. What the certified parts change is how much work the device evaluation involves.

PSA Certified describes four options for the device maker:

• Certified system software on a different valid certified chip (“flexible composition”). This needs the system software to have been certified with questionnaire v2.1 or newer.
• Certified system software on the chip named in its certificate.
• Uncertified system software on a certified chip. The evaluation must then also cover the system software.
• Neither layer certified. The evaluation must then cover both the system software and the chip.

For flexible composition, a valid chip is one that holds a Level 1, 2 or 3 certificate and provides any Application Root of Trust functionality the system software relied on for its own certification. If you build on certified silicon and certified system software, the device maker answers only about 20 device-level questions. Section 3.7 of the questionnaire also lets a new device reuse a certification that declared the same system software and chip.

The engineering consequence is easy to miss. If you second-source a chip, remember that a device certificate is valid only for its original system software and chip combination. Plan for that when writing the bill of materials, not after the swap.

What secure boot and root-of-trust evidence does a PSA Certified assessment expect from the device maker?

At device level, the device must enforce secure boot for the PSA-RoT, for any Application RoT services and for at least the first executable image of the non-secure software. The boot process must also keep the device secure if something fails. The questionnaire asks the developer to describe how a secure boot failure is handled. Software updates must be checked for authenticity and integrity. Anti-rollback is strongly recommended but not mandatory in Level 1 v3.1. The device must be uniquely identifiable, and that identity must be included in any attestation claim set. Critical security parameters must be unique per device or set by the user, and must never reset to a universal factory default. Interfaces the intended use does not need must be closed. Plan the cryptography carefully as well: RSA-2048 will not be accepted in products certified from 2027 onwards.

The questionnaire also states its operating assumptions. The manufacturing process ensures the integrity of hardware and software, and the injection of secret data keeps it confidential, so private keys are never shared between devices. These are stated as assumptions about the operational environment, not as questionnaire requirements.

Diagnostic checklist: can you show your secure boot chain?

The Secure by Design Handbook lists what a secure boot implementation should be able to demonstrate. It works as a pre-submission checklist:

• Hardware-anchored root of trust. The chain starts from immutable code or a protected trust anchor.
• Full chain verification. Every mutable boot component in scope is verified before it runs.
• Protected signing keys. Private keys are generated, stored, used, rotated and revoked under controlled conditions.
• Provisioning evidence. Fuses, certificates or key hashes for production devices are provisioned and recorded.
• Rollback protection. Version counters or equivalent controls prevent unsafe downgrade.
• Secure recovery and fail-secure behaviour. A failed boot recovers to a known-good authenticated state and never falls back to running unauthorised code.
• Debug lockdown. JTAG, SWD, UART and manufacturing interfaces are disabled, fused off or strongly authenticated before production.
• Technical documentation. Boot architecture, signing process, provisioning records, tests, exceptions and release configuration are kept on file.

Verified boot and measured boot do different jobs. Verified boot stops unauthorised code from running. Measured boot records what ran, for later attestation or forensics, and on its own it does not necessarily prevent anything.

How PSA Certified relates to ETSI EN 303 645, TS 103 701, SESIP and the CRA

ETSI EN 303 645 is a set of outcome-focused baseline provisions for consumer IoT devices. Devices intended mainly for manufacturing, healthcare or industrial use are out of its scope. The standard defines security requirements but no testing or certification method. ETSI TS 103 701 fills that gap with a conformance assessment method built on an Implementation Conformance Statement (ICS) and Implementation eXtra Information for Testing (IXIT). TS 103 701 supports self-assessment, assessment by a customer organisation and third-party assessment by an independent testing organisation, and it leaves the design of any certification scheme out of scope. Which of those modes a market or retailer accepts is decided by the scheme it uses.

PSA Certified Level 1 maps to EN 303 645. The Level 1 questionnaire includes an appendix mapping to EN 303 645, NISTIR 8259A, NISTIR 8425 and ioXt. Mapping is not substitution. Under TS 103 701, an existing certification of part of the device can serve as partial evidence only. The test lab must still check that its scope, test activities and assurance depth match each test group before it can pass that group without testing. The rest of this article relies on that rule.

SESIP is an evaluation methodology based on Common Criteria. It defines five assurance levels and is built around composition and reuse of certified components. The SESIP mapping to EN 303 645 is explicit: SESIP security functional requirements are not evidence of EN 303 645 conformance in themselves. They are evidence of the security guarantees the device application relies on to meet the provisions. SESIP also gives chip vendors a choice at Level 3: they can go through the informal CSPN-style profile or the SESIP profile, and PSA Certified suggests the SESIP route if the certificate will be reused in a larger composed certification.

Level 1 v3.1 also includes certification options covering the UK PSTI Act, the adopted text of the EU Cyber Resilience Act, the work-in-progress Radio Equipment Directive cybersecurity requirements and NIST 8425 for the US Cyber Trust Mark. Under the CRA, secure boot is a common technical control for the requirement to protect the integrity of programs and configuration.

How much does PSA Certified cost, and how long does an assessment take?

What PSA Certified does publish is lab effort: 25 man-days for a Level 2 chip evaluation and 35 man-days for Level 3. Those figures describe the chip vendor’s evaluation; with certified silicon and system software, the device maker does not repeat those layers. For the device maker, the Level 1 workload depends on composition. The roughly 20 device-level questions apply on the easiest route, where both chip and system software are already certified. The lab may ask for clarification during review and we found no published elapsed time, so we would ask candidate labs for dates before committing to a launch.

Building or buying the root of trust

To test an in-house integration estimate, add certification and supply-chain contingency to it and compare the result with the tapeout date. Whichever path you choose as primary, qualify an off-the-shelf fallback early enough that switching to it does not itself cause the slip.

What would building our own secure-element integration really cost compared with licensing one?

Beyond the unit price, each path carries certification work, provisioning-line changes and years of key maintenance. TechnoLynx runs this comparison as an independent, vendor-neutral study under the AI Porting & Deployment Pack. It starts by framing the decision against your volume, timeline and security requirements. It then shortlists proven secure elements and provisioning toolkits, costs the in-house path including certification and provisioning-line changes, and delivers a hidden-cost breakdown for the board decision.

One 2026 industry cost estimate (Success Knocks) puts a secure element or hardware root of trust at $0.50 to $5 per device at manufacturing. Treat that range as framing only, not as a quote. The same source describes security at scale as a recurring operational cost that covers certificate lifecycle management, monitoring and patching labour.

Some off-the-shelf options come with provisioning included. Microchip describes its Trust Platform as pre-provisioned or customisable secure elements, with credentials generated inside the secure element’s boundary using HSMs. It is offered in three tiers (Trust&GO, TrustFLEX, TrustCUSTOM), and Trust&GO starts at a minimum order of ten units. On the certification side, building on certified silicon and certified system software keeps your Level 1 work to the device layer. An uncertified chip pulls the chip and system software sections into your own evaluation.

These hidden costs should be itemised, not assumed:

• Certification. Count the device-level evaluation, any uncertified chip or software layers, and that a device certificate covers one chip and software combination only.
• Provisioning line. A controlled provisioning ceremony covers manufacturing stations, HSMs, secure elements, certificates, manifests and audit logs.
• Maintenance. Operational keys and certificates must be rotatable, renewable and revocable throughout the support period, and EN 303 645 requires the manufacturer to publish that support period.

Our judgement: license a proven secure element and toolkit when time to market is tight or in-house security expertise is thin. Build only when differentiation or cost-at-scale savings clearly outweigh the certification, maintenance and provisioning overhead a full comparison reveals. Check any vendor claim of “proven at volume” against your own production scale and geography. A feasibility study’s numbers also become less reliable the further your situation is from the reference deployments it examined.

Whichever path you take, each device must be uniquely identifiable, and that identity must appear in any attestation claim set. The Secure by Design Handbook expects the evidence pack to tie key decisions to hardware revision, firmware release, manufacturing batch and support period, and to keep provisioning logs, certificate records and exceptions. Once more than one SoC revision or vendor is expected over the product’s life, we would normalise those records in a cross-vendor store from day one rather than rely on each chipmaker’s tooling.

Will a retailer accept PSA Certified where an EN 303 645 self-declaration might be rejected?

PSA Certified certification relies on third-party evaluation labs. Whether a retailer accepts it, or accepts a self-declaration, depends on the scheme or questionnaire the retailer uses, as covered above.

Under ETSI TS 103 701, a self-declaration is a first-party assessment, distinct from third-party assessment by an independent testing organisation. If the retailer’s questionnaire asks for a recognised third-party standard, we would pursue PSA Certified Level 1 for the device, keep EN 303 645 conformance as the floor it maps onto, and confirm the retailer’s exact wording before committing. A self-declaration-only interim step makes sense only if the timeline forces it and someone formally accepts the risk.

For a signed-OTA claim, we would give customer security teams root-of-trust and secure-boot chain evidence, a mapping to a baseline such as EN 303 645, and a signed release record kept current. The baseline itself requires a device that receives updates over a network to verify the authenticity and integrity of each update through a trust relationship. We cover the update path in depth in anchoring OTA signing and attestation to a hardware root of trust.

Who can pull datasheets, firmware signing logs and emails into one audit-ready evidence pack?

TechnoLynx builds an audit-ready pack as a mapping exercise. Each retailer questionnaire item is traced either to an artefact you already hold or to a gap you still have to close. TechnoLynx assembles that pack as an engineering deliverable under AI Governance and Trust. It obtains the retailer’s questionnaire and maps it against your datasheets, firmware signing logs and correspondence. It then runs a traceability audit for coverage and gaps, recovers missing secure-boot or provisioning artefacts together with your provisioning process, formats the pack for the reviewer, and supports follow-up questions after submission. We treat that evidence as an engineering output that a buyer or auditor can read and sign against. It is not legal advice and not a certification.

This engagement has limits. If the gaps are in the secure-boot or signing process itself, not in the paperwork, the pack cannot be made audit-ready until those technical gaps are closed. Certification itself sits with a PSA Certified evaluation laboratory and the PSA Certification Body. A team that already keeps its EN 303 645 records current, with signing logs it can reproduce, may need only a review rather than an assembly job.

A useful structure is EN 303 645’s Annex B table, which records each provision with its reference, status, support and implementation detail, together with a recorded justification for each recommendation that is not applicable or not fulfilled. TS 103 701 then turns that record into assessment inputs through the ICS and IXIT. A useful pack lets a reviewer trace every public claim back to a provision, a product boundary, an implementation detail and a test result.

Turnaround depends on what you already hold: we would expect complete signing logs and datasheets to make it a formatting job, and missing provisioning evidence to make it recovery work.

A gap found in week four: vendor letter, targeted retest or delta review?

The fastest credible fix depends on what kind of gap you have found. For a documentation or configuration gap, we would try a vendor attestation letter or supplementary documents first. For a gap in functional security behaviour, such as secure boot failure handling, we would retest that one requirement. For a gap the scheme says must be revalidated independently, we would ask the certification body for a scoped review. We would treat that last option as the most credible and the slowest.

The schemes allow for narrower re-work. PSA Certified’s certificate numbering explicitly provides for a delta certification. Under TS 103 701, if a recommended provision fails, all other assessment results can be reused towards an overall pass once the ICS drops that claim and gives a justification.

Two cautions apply. External evidence counts only if the lab judges its scope, test activities and depth adequate for the test group. And a targeted retest closes the gap only if the root cause has been correctly isolated.

Which published standard should our root-of-trust attestation evidence trace to?

Trace it to the standard the OEM’s request actually describes, and name that standard explicitly in the pack. If the request reads as protect, detect and recover controls for platform firmware, NIST SP 800-193 is the natural baseline. If it is about device identity and remote attestation chains, TCG DICE with the IETF RATS architecture fits better. Where both concerns appear, we would map to both.

PSA Certified Level 1 requires the system software to support an attestation method proving the device is genuine, which should bind each report to the chip through a PSA-RoT attestation key or equivalent. SESIP’s catalogue groups the matching functions under Identification and Attestation, which demonstrate that a platform is the expected one and in the expected state. Measured boot supplies the records attestation relies on.

So can existing TPM, HSM or TEE attestation data be reused? We would reuse it as the technical core, but only after a gap analysis against the chosen standard’s controls. New instrumentation belongs only where that analysis shows a real gap.

Should an external lab certify our secure boot chain before the retailer submission?

If the retailer asks for independent certification, we would say yes and start scoping immediately. In our view, lab queues and evidence gaps put a listing date at more risk than the technical work does. TechnoLynx can map the retailer’s requirement to the closest scheme, assemble the root-of-trust and secure-boot package (design documents, threat model, boot-chain proofs, test results) for lab submission, help fix implementation gaps before review, and answer the lab’s evidence requests to keep the schedule. The certificate itself comes from the scheme’s lab and certification body, not from TechnoLynx.

On ioXt specifically, PSA Certified Level 1, 2 and 3 credentials are cross-recognised by ioXt. PSA Certified silicon automatically satisfies specific ioXt test cases. PSA Certified also states that UL recognises it as a fast track to UL’s Secure IoT Component Qualification. Whether any of these satisfies a particular retailer is a question for that retailer, not something the scheme can answer.

If the retailer names a scheme, pursue that scheme. If it only says “independent certification”, compare its wording with each candidate scheme’s published requirements and pick on fit and lab availability. As covered in the cost section, published lab effort is not a quote, so get early quotes. If lab lead time plus evidence preparation overruns the deadline, the options are to ask the retailer for flexibility, choose a faster scheme or lab, or submit an internal attestation with a certification-in-progress letter if the retailer accepts that interim state.

What an EN 303 645 secure-boot evidence pack contains for a retailer audit

We would build an EN 303 645 secure-boot evidence pack from the boot-chain, trust-anchor, signing-key and test evidence a secure boot design should show, traced to its provisions. TechnoLynx does the engineering behind that pack. It maps the product’s EN 303 645 secure-boot provisions to the boot-chain design, brings up and validates the chain of trust on the target hardware (an nRF5340, for example), documents the architecture, provisioning process and test results, builds the traceability matrix, and advises whether the retailer’s requirements call for an independent attestor.

One detail shapes the pack. In EN 303 645, secure boot is phrased as a recommendation: the device “should” verify its software using secure boot, and a hardware root of trust is named as one way to provide strong attestation. If a recommendation is not applicable or not fulfilled, EN 303 645 requires a recorded justification, so that assessors, supply-chain partners and retailers can judge whether the provisions were applied correctly. The standard also expects the device to alert the user or administrator when it detects an unauthorised software change, and recovery from a locally stored known-good version is one way to recover.

Who can independently attest that the chain-of-trust validation was done correctly? EN 303 645 defines no testing or certification method, and it says third-party assessment is likely to require architecture documents, threat models and certificates for the components used. Where independence is wanted, TS 103 701 supports third-party assessment by independent testing organisations. Whether you need a third-party assessment rather than a self-assessment before the retailer’s audit is decided by the scheme the retailer uses. An internally produced pack carries only as much weight as the rigour of the validation behind it, so confirm the format with the retailer before you build it.

Evidence that survives the next version of the scheme

These schemes are still changing. PSA Certified Level 1 added a regulatory section that quotes the EU’s standardisation request for RED, and PSA Certified plans to add the harmonised standard once it is available. ETSI’s draft EN 304 623 shows how CRA expectations may become testable boot-manager requirements, covering verified boot, rollback protection, key provisioning and assessment evidence. We would organise a pack around provisions, product boundaries and dated test results so it can be re-mapped when the questionnaire changes. For the same reason, keep provisioning records per device and per silicon revision from the start.