What Is Platform Security Architecture (PSA)? Definition

Platform Security Architecture (PSA) is a security framework for connected devices that defines threat models, security goals, and implementation guidance from silicon to software. It helps vendors build trustworthy IoT and embedded products with consistent controls. Defenders use it to assess whether devices support secure boot, attestation, isolation, and update protection.

What PSA covers across the device stack

Platform Security Architecture is useful because it treats device trust as a layered problem, not a single control. A strong PSA defines where trust starts in silicon, how it is measured and extended through firmware and operating systems, and what guarantees the platform must preserve as software is loaded and updated.

That makes PSA especially relevant for connected devices that need repeatable security properties across many product lines. It gives vendors a common way to describe what a device should prove about itself, and what a defender should expect to see before the device is allowed to operate in a larger environment.

Why secure boot, attestation, isolation, and update protection matter

The practical value of PSA is in the controls it tries to make consistent. Secure boot helps ensure that only trusted code starts the device, attestation lets another system verify the device state, isolation limits the blast radius when one component is compromised, and update protection reduces the chance that an attacker can replace trusted software with a malicious image.

These controls matter because embedded and IoT devices often sit at the edge of the trust boundary, where a weak boot chain or poor update path can turn a small device flaw into persistent compromise. PSA is therefore less about one product feature and more about whether the platform can maintain trustworthy execution over time.

How PSA is used by vendors and defenders

Vendors use PSA as an architecture reference when they decide which security capabilities belong in hardware, firmware, and higher-level software. It is most valuable early in design, because decisions about root of trust, measurement, isolation, and update handling become harder to retrofit after deployment.

Defenders use the same architecture to assess whether a device family exposes meaningful control points for validation and response. A device that cannot prove its boot state, cannot isolate sensitive functions, or cannot protect its update path creates a very different assurance profile than one built around a verifiable trust chain.

For broader platform and endpoint hardening patterns, see the Endpoint Security Guide, and for connected-device environments that depend on cloud-side policy and logging, the Cloud Security Guide is a useful companion reference.

What weak platform architecture usually looks like

PSA failures often show up as gaps in trust continuity. If the platform cannot establish a reliable root of trust, if measurements are not available for verification, or if update mechanisms can be bypassed or downgraded, then the architecture may look secure on paper while remaining easy to subvert in practice.

That is why PSA should be read as an end-to-end trust model rather than a checklist of isolated features. The important question is whether the device can preserve integrity from power-on through runtime and maintenance, not whether it advertises a few security capabilities in isolation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-7 — Software, Firmware, and Information Integrity	PSA centers on trusted boot, integrity, and update protection for connected devices.
	CM-5 — Access Restrictions for Change	PSA depends on controlling who can alter device software and platform state.
	SA-10 — Developer Configuration Management	PSA is an architecture choice that must be governed during product development and release.
Recommendation — Apply SI-7 to verify firmware and software integrity before and after deployment. Use CM-5 to restrict platform changes to authorized maintenance paths. Use SA-10 to manage platform security baselines through the product lifecycle.
ISO/IEC 27001:2022	A.8.9 — Configuration management	PSA requires controlled platform configurations across hardware and software layers.
Recommendation — Establish controlled configuration baselines for device platforms and updates.
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	PSA is fundamentally about secure platform configuration and trustworthy defaults.
Recommendation — Standardize secure platform configurations and verify they stay intact.

Practitioner Guidance

Why practitioners should care: Treat PSA as an assurance framework, not a marketing label. The useful test is whether the platform can prove its security claims across boot, runtime, and update lifecycle, especially when the device is deployed in untrusted or hard-to-reach environments.

What to watch for: Be cautious when a device family has vague claims about secure boot or attestation but no clear story for key trust anchors, isolation boundaries, or update integrity. Those gaps usually indicate that the security model is incomplete or difficult to verify at scale.

Practitioner takeaway: The strongest PSA implementations make trust measurable, repeatable, and hard to bypass, which is what turns device security from an assumption into an architecture property.

Platform Security Architecture (PSA)