NEWSROOM

Arm Newsroom / Blog

BLOG | OCTOBER 22, 2021

Security Design Best

Practices Mean Trust and
Certification
Third-party certification can aid device makers in ensuring a consistent
standard of security is designed into the hardware and firmware of all
devices, and the Arm ecosystem has a vital role to play in this.
By Wouter Slegers, CEO, TrustCB

Security

Share     

We’ve reached a crossroads in cybersecurity efforts in an increasingly

complicated era of development. On one side, consumers want to be
able to trust the security in their devices. On the other side, among
technology providers, there seems to be a reality gap: In a
recent survey by PSA Certified, 87 percent of respondents said they’re
satisfied with the quality of IoT security implementations within their
company.

However, 84 percent of the companies that have adopted an IoT

strategy have reported a security breach. Clearly the self-developed,
self-assessed security implementations are not providing what
everyone – except for cybercriminals – wants: trusted security in their
digital devices. The trick is charting the right course to ensure that
happens.

Governments and regulatory bodies, reacting to the headlines and a

perceived lack of industry progress, are increasingly enacting
standards, laws and rules outlining how security needs to improve.
Companies, on the other hand, tend to want to ensure their products
will be easily certified in components, enabling reuse of certification in
the interests of time, efficiency, and money.

This combination of forces demonstrates what should be the path

forward: third-party certification and attestation to do security
evaluation once and reuse it efficiently.

Certification and attestation is the two-step dance that ensures that, at

the hardware level, devices are what they say they are, and going up
the software stack, at the product level, validates they are still
providing the expected level of security. It enables longevity in the
security of connected devices, and an audit trail to ensure best
practices are being followed in the supply chain and in the usage.

As the world looks to well-known laboratories and certification

authorities to certify the security robustness of countless consumer
devices, so too is it beginning to look to our industry for similarly
making development, evaluation, and certification fast, easy, and
predictable in a modular fashion. The good news is the solution
development has been underway for a long time; the challenge is
building on the momentum to ensure that industry properly self-
regulates and avoids overly heavy governmental intervention.

One-two punch
The two-step approach to enabling more trusted devices is split
between hardware and software platforms (the chips and the OS), and
making these into end products (the doorbells, voice assistants, and
such).

The first step, certification of the platforms, is validation against well-

defined requirements that the platform provides the secure
functionality as advertised. Developing such secure functionality and
evaluating its robustness against serious attackers is an important,
niche skill. But once that functionality is known to be secure, it is easy
to use that functionality and make a secure product out of it.

This makes the second step easy: The product developer will rely on
the secure platform, and focus on the distinctive functionality to make
the product. Thus, certification makes it easy to ensure that your
digital doorbell or voice assistant is secure and attestation shows your
supply chain security credentials are in order.

Police thy self?

Many companies (62 percent in that PSA Certified report cited earlier)
have relied on self-certification to ensure for their customers that their
products are trustworthy.

This has the benefit of being controllable by the company and is usually
expedient. But this approach is not robust enough (especially if the
threat model isn’t well-rounded, or in many cases is non-existent) and
has a number of challenges.

First, pity the internal compliance administrator urged on by a boss to

certify the product so it can get to market quickly. Certify now and risk
some vague, potential issues years in the future to be handled by the
people over at the security response team then? Or refuse to “be
flexible with the rules,” delaying certification and risk getting fired? Are
most companies even staffed properly to handle what could be scores
of required certifications depending on their product portfolio? Are
they positioned to consider every potential breach, especially as the
threat landscape evolves? Or will they introduce a serious technical
depth of potential security issues in the future, especially in the IoT
domain with long operational deployment?

Second, self-certification failures have been prompting severely

stricter regulatory requirements, especially where critical
infrastructure and societal damage is at stake. And, while there are
some logical reasons for a company to self-certify, it also means the
company takes on liability for those claims. Lastly, self-certification
isolates the interpretations of the requirements – highly relevant in the
security domain – which can lead to a market of siloed developments,
disparate, proprietary solutions, and an uneven playing field.

Third-party certification ensures consistent

standards
Enter third-party certification, which has historically had a strong basis
in the governmental eID and payment industry. Device makers can
ensure a consistent standard of security is designed into the hardware
and firmware of all devices, and the ecosystem has a vital role to play in
this.

We all need to work together to identify and share industry best

practices, so we can overcome current and future security threats and
make sure everything is built on a common foundation of security and
trust. This works so well that vulnerabilities in the eID and payment
card domains are rare nowadays. Surely this is desirable for our
consumer IoT, critical infrastructure, and personal privacy? And, it
suggests that additional security goals can be achieved.

The second prong, attestation, comes as the products are delivered

and function in the field. Attestation is a technical means to make sure
a product is genuinely what it claims to be, and still operates in a secure
manner. Attestation can be used to translate the human-readable
certificate of trust into something that’s machine-readable.

Previously, to attest to the trustworthiness of a device, you had to take

the package off a silicon device and examine its markings to ensure it
was what it said it was. This isn’t very practical even for the
professional evaluation labs, let alone end-consumers, and also is
vulnerable to forgers.

Today, to manage this better and ensure scalability, devices have a Root
of Trust that can provide the attestation chain from chip to full system.
A product with this functionality can prove to its owner and the other
devices and services it’s talking to that it is genuine and trusted, and
those other devices in turn can trust it. It’s a key element of securing a
device throughout the lifecycle, and showing the value of secured
devices to the network it is in.

PSA Certified, founded by Arm in 2017 to provide a security

framework for the IoT sector, has developed so that today it has more
than 70 products PSA Certified across the world.

An ecosystem of trust
Technology alone isn’t enough to make an ecosystem. We at
TrustCB are just one aspect of a rapidly expanding certification and
attestation ecosystem that aims to ensure trusted, validated security
from IP to system.

These include partnerships such as PSA Certified (founded by Arm,

Brightsight, CAICT, Prove & Run, Riscure and UL) which is an open,
industry-standard threat-modeling framework to ensure secure-by-
design up through and including security consultation, evaluation, and
finally certification. PSA Certified is also concentrating on aligning with
other schemes (such as GlobalPlatform SESIP, UL IoT Security Rating
and ioXt Alliance) to further reduce fragmentation and improve the
composite certifications reuse in other schemes.

In the end, third-party certification sets a common bar for everyone to

protect the connected world. This enables companies to use
certification to build or expand a trusted brand and position against
competitors that have avoided certification or employed self-
certification. And because it’s an ecosystem of companies dedicated to
making the digital world more secure, it’s trusted: These companies put
their reputations and business models on the line in the name of
security certification.

The business value to the certification ecosystem is shorter time-to-

market. Developers need to make a secure end product fast. One can
risk time to market using a component of unknown security: Finding
out that a core mechanism that’s depended on for the security, is in fact
insecure causes a very expensive rush to fix late in the development
cycle (even more so if that core mechanism is provided by another
party).

Thus the evaluation and certification process needs to be predictably

short. The time the product is in limbo for its security certification is
very costly to developers and reduce security for all. After all, the
attackers do not wait.

Some smaller companies worry that certification schemes could add

costs to their product development that, because of their size, they
can’t afford. It is quite the opposite: Certification and attestation help
the ecosystem spread the cost with the reusable certifications of the
platforms.

For example, a company taking a small control and communications

module and layering software on top to make it a solution for farm
irrigation now only has to worry about certification of its software
running on the module. The security of the underlying hardware and
OS has been validated and certified, and those costs are spread over
the many users of that hardware and OS.

In short, through certification and attestation, companies now see a

pathway to trust, just as much as they realize that the cost of inaction
can be incalculable.

Read the 2021 Arm Security Manifesto

The third Arm Security Manifesto surveys the threat landscape today
and details the tremendous strides the industry has made in the past
four years.

Read Now

By Wouter Slegers,
CEO,
TrustCB

Share     

 Article Text Copy Text 

Any re-use permitted for informational and non-commercial or personal use

only.

Editorial Contact
Brian Fuller and Jack Melling
[email protected]

Subscribe to Blogs and Podcasts

Get the latest blogs & podcasts direct from Arm

Email
[email protected]

Country
Select Country / Region

Arm will process your information in accordance with our Privacy Policy.

Subscribe

Related
B LO G | O C T 1 1 , 2 0 2 1

Cybersecurity: Do You
Hear the Tiger in the
Grass?
Matthew Griffin, Fanatical Futurist
and Founder, 311 Institute and
World Futures Forum

B LO G | AU G 0 5 , 2 0 2 1

Read the 2021 Arm

Security Manifesto
Arm Editorial Team

Media Information

Company Arm
Overview Corporate
& History Guidelines
Arm is defining the Information on how to
future of computing use the Arm corporate
logo

Media
Contacts
Get the latest Media
contact information

Latest on X

Arm 14 May Arm 14 May Arm 14 May

; ; ;
Great conversation yesterday Is AI the new engine of Stable Audio Open Sm
at @SelectUSA Investment creativity? built on Arm CPUs by
Summit on how public-private @StabilityAI - is now
collaboration can drive Join Arm CMO, Ami Badani, at
innovation and resiliency in @Tribeca Festival as she and What’s new?
the semiconductor industry. leaders from the AI and Step-by-step lear
creative ecosystems explore for Android deploym
Arm CEO Rene Haas shared how a new generation is using Open-source cod
Arm’s perspective on building AI to unlock creativity at copy, run, or drop int
the future of computing and unprecedented scale. Behind own app
why U.S. investment and it all is Arm, delivering the
talent… compute platform… Build it. Remix it. Sha
Get started:
https://okt.to/YXyZv

5 14 Twitter
1 7 Twitter

Products
CPUs & NPUs

Arm Immortalis & Mali

Physical IP

Security IP

Subsystem IP

System IP

Development Tools

License Arm Technology

Architecture
Learn the Architecture

CPU Architecture

System Architecture

Architecture Security Features

Partner Ecosystem
Join Partner Program

See All Partners

AI Partners

Automotive Partners

IoT Partners

Support & Training

Documentation Hub

Downloads

Contact Support

Support Forum

Training

Design Reviews

Education

Research

Company
Leadership

Investors

Arm Offices

Newsroom

Careers

Quality

Trust Center

Suppliers

Regional Newsrooms
English

⽇本語

中⽂(台灣)

Terms & Policies Terms of Use Privacy Policy Suppliers Accessibility

Subscription Center Trademarks Modern Slavery Statement Glossary

Copyright © 1995-2025 Arm Limited (or its affiliates). All rights reserved.