FUNCTIONAL
SAFETY AND
SECURITYESSENTIAL ANDCOMPLEMENTARYDISCIPLINES FOR
MODERN SYSTEMSFunctional safety and security are well-known andimportant design principles in many industries. This
whitepaper provides a global introduction to andcomparison of the functional safety and security domains
and their individual aspects. It is intended to help
executives, practitioners and experts familiar with oneof the two domains to broaden their knowledge of theother and to identify synergies and interdependencies.
Additional whitepapers focusing on select topics in moredetail will follow this publication.
INTRODUCTION
Functional safety is a very wellestablished design principle inmany industries. Its primary focus
is to reduce injury or health risks tohumans to an acceptable level whenusing technical equipment, but it also
includes reducing the risk of damage
to property or the environment. It
addresses human errors, tool errors,
typical technical failures, and often
results in system monitors andredundant implementations that arerobust in multiple ways. Obviously,
this requires an end-to-end viewin the assessment of these risks
and for finding the appropriatesolutions. Functional safety reviews
always involve verification and anassessment or even a certificationof the effectiveness of the measures
implemented on the product andprocess sides.
Security is also required in manyindustries to protect any kind of user
asset from being accessed unlawfully,
one way or another. These assets
are manifold and include monetary
assets, intellectual property rights, or
any kind of private data. Protection ofintegrity, authenticity and availability
are other objectives in security, andhere we see a strong overlap withfunctional safety.

COMPONENTRELIABILITY& ROBUSTNESSFUNCTIONAL
SAFETYwww.nxp.com

SECURITY

2CLOUD CONNECTIVITY
CREATES NEW SAFETY
AND SECURITY THREATS

New cyberphysical systems needboth safety and security features

Threat of remote attack
Sensitive data

Control functions

THE RELATIONSHIP BETWEEN FUNCTIONAL SAFETY,SECURITY AND SYSTEM SAFETY
As outlined above, functional safety aims to reduce
the risk of unintended hazards, caused by malfunctionof one or more system components, whereas securityaims to reduce the risk of intentional threats, caused byhumans. So, why have safety and security traditionallybeen separate disciplines? Is functional safety the same assafety?
Let’s start with the first question. Security traditionallyapplies to systems that contain or process secrets or othersensitive data, such as personal devices and ICT systems.
Functional safety traditionally applies to embedded
systems that have a dedicated control function. These
embedded systems are housed within larger electromechanical systems and they interact with the physicalworld around us. Due to this interaction, these embedded
systems typically have strong safety requirements. Atrend we see today is that these “physical” systems
are increasingly connected. This connectivity enriches
these systems and adds situational awareness throughinformation exchange with nearby devices and in-thefield introduction of new features and bug fixes throughover-the-air (OTA) updates. This connectivity also exposes
these systems to new cyberthreats, i.e., humans may try to
attack these systems remotely. There is a new, emerging
category of devices with safety and security aspects.
These devices are sometimes called “cyber-physicalsystems.”
Now to the second question. It is intuitive to understandthat operational safety is a must-have for physical electromechanical systems; the risk of harm to persons should
be minimized during operation of the system. So how
do functional safety and security relate to operationalsafety? Both help to achieve operational safety. Withoutthem, unintentional hazards or intentional threats could
negatively affect the functions implemented in theelectronics of the system that control the operation ofthe system. Operational safety itself is only one aspect ofsafety at system level. Other aspects include electrical,
3

mechanical and chemical safety. Hence, system safety
typically depends on operational safety, which itself
depends on functional safety if electronics and softwareare involved. It also often depends on security, especially
if the systems are connected and more easily subject toattacks by humans. The Jeep hack that occurred a few
years ago is a perfect example. The hackers managed
to break into the radio. Once inside the vehicle network,
they could control various safety functions, including thebrakes, and thus negatively affect operational and systemvehicle safety.
Operational Safety

Electrical Safety-Functional Safety-Security

Chemical Safety

Mechanical Safety

SYSTEM LEVEL SAFETY
A much more technical and detailed comparison offunctional safety and security can be found in IEC TR63069, “Industrial-Process Measurement, Control andAutomation – Framework for Functional Safety andSecurity.” The basis for functional safety is set by IEC
EN 61508, “Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems.”
Other standards, such as ISO 26262, “Road vehicles– Functional Safety,” have built upon this original
work to provide similar frameworks tailored to specificmarkets and applications. Similar standards are also
being developed for security, including ISA/IEC 62443,“Industrial Communication Networks – Network andSystem Security,” and ISO/SAE 21434, “Road Vehicles –Cybersecurity Engineering.” Furthermore, new standards
such as ISO/PAS 21448, “Safety Of The Intended
Functionality (SOTIF),” are being developed to address
safety at a system level.

www.nxp.com

COMPARISON
In essence, in order to achieve functional safety, it isimportant to have a holistic end-to-end view of the system
in question to understand the potential risks. Indeed,
any analysis of an element or a subsystem malfunction
must look at it as a standalone malfunction and as thepropagation of this malfunction into the system. Ultimately,
the analysis must evaluate the criticality on the overallsystem. Likewise, it is paramount in security to make anend-to-end assessment of all relevant ways to breach thesecurity of the system. In a typical “hack” of a system
the hacker requires a number of stepping-stones before
reaching the target. The aforementioned Jeep hack is afamous example in which the car radio was the initial entry
point for the attack. In the end, because of all subsystems
being connected to each other, the entire system wascompromised, including the car’s brakes. As end-to-end
assessments tend to be very complex, we will still want topartition the system as much as possible to keep the scoperequired for the analysis as small as possible.
In functional safety as well as in security, the analysis starts
with a definition of the assets that need protection. Thisis a straightforward act in functional safety; it is generally
the health of the people exposed to the system, possiblyextended to refer to an entire environment. In security,
assets may differ from case to case. In the case of anelectronic wallet, it is the money contained in that wallet.
For a video game manufacturer, it may be their intellectual
property contained in the software. In fact, the firmwareof devices often contains intellectual property that needs
protecting. Hence, there is an overlap in attributes
protected by the two domains. They both aim to protect
integrity and availability, but security’s scope is broader as
it also aims at protecting confidentiality and authenticity.
The next step in security is to establish a threat model anda set of attack vectors. This is where we see substantial
differences between functional safety and security. Firstof all, notations are somewhat different: functional safety
starts with a hazard analysis and risk assessment (HARA)
that is conceptually comparable to a threat modeland later analyzes failure modes that are conceptuallycomparable to attack vectors. In the case of functionalsafety, there is a collection of possible user mistakes,
development errors and inadvertent technical failures ofthe system that need to be covered. This is a more static
picture and changes only slowly over time when new
insights are gained, such as when new technical failuremodes are discovered, new health risks are identified,or legal requirements change. The security threat model
defines what type of attackers are considered. It identifies
their capabilities and, in particular, how close they can
get to the system, i.e., only remotely via internet, or evenphysically with the device in the hands of the attacker.
Obviously, the assumed capabilities of the attacker have amajor impact on the security solutions required. This is amajor difference with functional safety for which the faults
happen inadvertently and randomly during operation. In
contrast, security attacks are intentional. What’s potentiallyworse is that the attacker becomes more proficient as
the attacks evolve to become stronger and cheaper overtime. This is the main driving force. And it does not stop
here—new attacks are found at an increasing pace all thetime. The Spectre and Meltdown attacks are a famous
example of when side-channel attack techniques wereused creatively. These techniques were familiar to otherfields, but were applied with
The risk analysis
dramatic success to modern
microprocessor architectures.
for functional
All this introduces an element ofsafety is moretime and aging to any solution,
quantitative inand with that also the need for
periodic field updates of possibly nature than the riskquite large parts of the software
analysis for security
stack to maintain the level ofsecurity required. In conclusion, which relies more
we can state that both domains
on estimations.
take a risk-based approach; therisk analysis for functional safety is more quantitative innature than the risk analysis for security which relies moreon estimations.

ATTACKS & HAZARDSOVER TIMEcAttadsazar

Hks &TimeAttacks

www.nxp.com

Hazards4

Another open point is the interaction between security
and functional safety and between the respective
components implementing them. Issues may be caused byunsafe or insecure component
Issues may beinteractions, none of whichcaused by unsafe
may have failed and, in fact,
satisfy their requirements.
or insecure
In particular, the reactioncomponent
to a fault or incident may
cause issues in other parts
interactions, noneof the system. For example,of which may
a security subsystem thathave failed and, insenses it may be under attack
might want to reset itself andfact, satisfy theirmaybe even other parts of therequirements.
system, including those that
implement safety functions.
However, it generally is not a good idea to “blindly” doso; reset may be considered a safe and secure state, but
it doesn’t necessarily mean that none of the safety goals
are violated. Such issues could be identified using existinghazard analysis methods, provided that there are crosschecks between security and functional safety concepts.
Other issues caused by unsafe or insecure interactions ofcomponents may only be found in operation as “unknownunknowns.” It is for that reason that there are initiatives
that investigate whether existing methodologies, possibly
from outside of the two domains, could be used to
identify and eliminate or mitigate such issues early inthe development process. One idea is to apply systemtheoretic process analysis (STPA) which, unlike thetraditional hazard analysis methods, can be started in early
concept analysis to assist in identifying safety and security
requirements and constraints. The idea here is to design
safety and security into the larger system architecture anddesign, starting with a global analysis in the early phases,
and refining it in later phases when the system design isrefined and more detailed design decisions are made.
The solutions to meet these design principles areusually cast in safety/security functions that need tobe implemented. The substantial overlap of security
and safety functions is one of the most obvious targets
for synergy between the two disciplines. An analysisof acceptable remaining risks is also needed, as there
is always a residual remaining risk no matter what
precautions are taken. In security, the acceptableremaining risk is often expressed as a minimum numberof points every attack needs to score in a suitableattack rating metric. In functional safety residual risks
are evaluated with a failure mode effect and diagnostics
analysis (FMEDA), which results in a probabilistic metric ofhardware random fault (PMHF), checked against a target
value defined by the necessary safety integrity level (SIL).
This brings us to the next commonality: in functionalsafety, as well as in security, it is good practice to perform
a verification of the claimed properties. This is donewith a set of tests that are as thorough and complete as5possible performed during the design stage, but also later
during the production of the product. At advanced levels
these tests will also involve formal proof of the claimedproperties.
Both domains apply similar roles and process steps. For
example, both domains require concepts and architectures
to be defined by experienced architects to prevent common
mistakes, reviews to be performed by independent reviewers
and assessments by security and safety assessors to confirm
that functional safety and security goals have been achieved.
Both domains require expert know-how and experience
with a typically steep and long learning curve; however, theexpertise and experience is different for the two disciplines.
Still, someone with good knowledge and expertise in one
discipline will be able to get started more quickly in theother discipline, though they still will not immediately be
an expert. Therefore, training is essential for both domains.
Typically, a combination of classroom and on-the-job
training is offered to grow talent. Furthermore, we see a
growing consensus that
Lastly, organizations
a single team or expert
cannot efficiently handle
need the right mindset
both domains in parallel.
to continuously
The trend is therefore
improve awareness andto establish close links
between both domains and to effectively addressexpert teams, and to haveboth domains. This
regular interaction andmindset should stemalignment between themthroughout both processes.
from the organization
Safety goals may be inputs
leaders to help build
to security process, andsecurity countermeasuresand nurture the safety
may need to be validated
and security culture.
by functional safety experts
in close and iterative loops.
Lastly, organizations need the right mindset to continuously
improve awareness and to effectively address both domains.
This mindset should stem from the organization leaders to
help build and nurture the safety and security culture.
When we look at regulation, then the picture is quite
different between (functional) safety and security. Safety
regulation is in place for many markets – including aviation,
railways, road transportation and medical applications– and compliance is typically enforced through typeapproval. Currently, legal requirements are often poorly
developed for security, although there are initiatives
for select markets. One such example is that the World
Forum for Harmonization of Vehicle Regulations (UNECEWP. 29) is developing a new International Whole Vehicle
Type Approval (IWVTA) scheme that includes security
regulation. Under this scheme, which Europe plans to
adopt and enforce in 2022/2024, a certified cybersecurity
management system (CSMS) becomes a prerequisite forvehicle manufacturers (OEMs) to achieve type approval for
new vehicles. Furthermore, suppliers will be required toprovide evidence of compliance to the OEM.
www.nxp.com

Compliance is a good and sometimes necessary step,
but may not be sufficient. In both disciplines, it is easy tomake claims, but it’s less easy to validate those claims. It
is therefore common practice for both design principles
to give customers more independent assurances ofthe quality and effectiveness of all the implementedmeasures. Firstly, an organization can be certified by anaccredited third-party for compliance with engineering
standards. This process certification is the major trend
in the automotive industry and the intent of the ISO
26262 and ISO/SAE 21434 standards. We expect thesame trend in the industrial market (IACS) with IEC 61508
and ISA/IEC 62443, and possibly in other markets, too.
Secondly, product certification can be applied to provide
assurance that the products fulfills its security and/or
safety objectives. This can be applied for functional safety.
However, self-assessment is also allowed by the standards,
provided that the assessor within the own organization has
sufficient levels of independence and expertise. In larger
companies, which usually have centralized functionalsafety teams with sufficient expertise and experience,the practice is to move away from product certification infavor of performing confirmation measures in-house.
There are currently a few industries that require productcertification for security. The most notable examples are
the banking industry with EMVCo standards and countries
with the Common Criteria standard (e.g., France). Also,
some areas of governmental interest, such as travel
documents, passports, ID cards, etc., often require a

www.nxp.com

Common Criteria certification with assurance levels
defined in the EAL metrics. Yet, for the much larger fieldof IoT, certification of security claims made for products
are still in their infancy. It could, however, be expectedthat this will change over time as security becomes more
and more critical for virtually every infrastructure. The
privacy laws now enforced in Europe are a first example ofthis trend. Arm® has recently launched a proprietary PSA
certification scheme for subsystems used in IoT products.
NXP founded an industry consortium that created theSESIP evaluation methodology/certification scheme which
addresses an even larger and more comprehensive part ofthe system stack in IoT products than PSA does.
Despite concept, design, implementation andconfirmation reviews by independent experts throughout
the development phase, possibly extended by process
and product certification, incidents with products in thefield can never be fully excluded. This is the case for bothdisciplines, and in both cases, there is usually pressure toquickly identify the root cause and define and implement
mitigation strategies and solutions to address these, as
the real-life impact may be significant. Furthermore, it isuseful to monitor devices in the field for anomalies. It is
for that reason that a security operations center (SOC), a
concept stemming from the information technology (IT)world, is now also being considered and, in some cases,
already implemented for operational technologies (OT)such as connected vehicles and industrial systems.

6Monitoring is also being considered
for safety, especially in the context
of SOTIF to detect for unknown
unknowns. However, there are also
differences; security has to deal withan evolving landscape, in which new
threats and attacks occur regularly
and where existing ones become
easier and cheaper to mount. It is forthat reason that organizations should
also implement threat monitoring tostay ahead of the curve.
CONCLUSION
There is a clear need for companies
to master both disciplines anddrive alignment between them.
The similarities between functionalsafety and security are surprisingly
strong. This should help anybody
with good knowledge and expertisein one area to get a head startin the other field. There are also
many potential opportunities forsynergies due to these similarities.
However, there are also significant
differences that can be spotted once

www.nxp.com

taking a closer look at the various
aspects of the two domains. The
main difference lies in the fact that
security is a more dynamic field,with new attacks being invented
all the time, and at an increasing
pace. Also, the malicious intent of
an attacker and their dedication tofind weaknesses and exploit themhas a huge impact on the natureof the security solutions that arerequired. By the same token, thisalso means that security is a rather
fast-moving target. Any proposedsolution needs to be revisited andpossibly updated and verified on aregular basis. Also, because of theever-increasing complexity and sheer
number of connected products within
a single ecosystem, the scope ofsuch an analysis keeps changing andwidening. To this end, appropriate
mechanisms need to be in place,quite possibly involving more than
one company along the value
chain of a product. However, theautonomous driving challenge willlead to a more dynamic environment

7

from a safety perspective as well. The drastic increase of
artificial intelligence usage in the vehicle and the potential
for collecting a huge amount of information throughthe cloud will generate a need for regular safety criticalapplication software updates. This involves a move froma hardware-based safety solution that is quite “static”
to a “hardware as a platform” safety approach allowing
a flexible but still safe software safety concept. As such,the safety integrity will have to be ensured all along
the supply chain: development, verification, update,deployment, etc. Following this autonomous path also
mandates an evolution from fail-safe to fail-operational
systems. This leads to an even bigger challenge forfunctional safety and security: how to keep the systemrunning after a fault or an attack?
Although security certification is still in its infancy for many
emerging markets such as IoT, it is strongly believed thata meaningful and independent security certification will
be needed for those markets to flourish sustainably. This
concept has been repeatedly proven to be successful
in many industries already, not just for security but alsofor (functional) safety. On the organizational processlevel, this requires engineering standards tailored tospecific verticals, such as ISA/IEC 62443 for industrialand ISO/SAE 21434 for automotive. This will require newcomprehensive evaluation methodologies/certification
schemes like SESIP that allow for a more flexible andmodular approach to product (re)certifications.

Both functional safety and security are already very
complex disciplines in their own right. As industries
increasingly require both, it is therefore paramount tomake these two disciplines compatible and remove
complexities and contradictions. This will requirealigning methodologies, metrics, processes, concepts,architectures, countermeasures, and, last but not least,
close alignment and interaction between disciplines andteams. Given all the commonalities outlined above, thisshould be an ambitious but achievable target; it’s also ahuge opportunity.
Companies that are strong in both fields are in an idealpole position to be leading players in the connected,
technically complex world of tomorrow, playing to theirstrengths and exploiting the synergies of these two designprinciples to the fullest, making sure they complement
each other in an integrated fashion.

www.nxp.com/safeassure
NXP and the NXP logo are trademarks of NXP B.V. All other product or service names are the property of their respective owners. Arm is a trademark or
registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. The related technology may be protected by any or all of patents,
copyrights, designs and trade secrets. All rights reserved. © 2020 NXP B.V.
Document Number: SAFETYSECWPA4 REV 0