Supplier Management Under ISO/SAE 21434: Clause 7 Explained

Supplier management under ISO/SAE 21434 comes down to three parts: check that a candidate supplier can do the cybersecurity work, put cybersecurity requirements into the request for quotation, and write down who does which cybersecurity activity in a cybersecurity interface agreement. Clause 7 of the standard sets these rules, and they repeat at every tier, because a Tier 1 that supplies an automaker is also the customer of its own Tier 2 suppliers.

Regulation is what turns this from good practice into a requirement. UN Regulation No. 155 (UN R155), the cybersecurity rule behind vehicle type approval in the markets that apply it, requires the automaker to show how its cybersecurity management system handles dependencies on contracted suppliers, and to identify and manage supplier-related risks for each vehicle type it brings to approval. Automakers meet that by passing requirements down the chain, and ISO/SAE 21434 is the common language they use to do it. For the bigger picture of why the supply chain is the hard part, see our post on securing the automotive supply chain.

What ISO/SAE 21434 requires for supplier management

ISO/SAE 21434:2021 is the joint ISO and SAE standard for cybersecurity engineering of road vehicles, published in August 2021. It is still the current edition. A second edition is under development and not yet published, so the clause numbers below come from the 2021 text.

Clause 7, "Distributed cybersecurity activities," applies whenever responsibility for cybersecurity work on an item or component is split between a customer and a supplier. It covers every phase where such an agreement applies, and the standard says internal suppliers can be managed the same way as external ones. The clause has three parts, and in practice they overlap during sourcing.

1. Check the supplier's cybersecurity capability

Clause 7.4.1 requires you to evaluate whether a candidate supplier can develop the item or component, and run post-development activities where those apply, in line with ISO/SAE 21434, and the standard notes that this evaluation supports supplier selection. It can rest on the supplier's ability to conform to 21434, or on how it applied another national or international cybersecurity engineering standard in the past.

The supplier is expected to help by providing a record of its cybersecurity capability. The standard suggests that record can include:

• evidence of cybersecurity practice across development, post-development, governance, quality and information security;
• evidence of continual cybersecurity activities, such as monitoring and vulnerability handling, and of cybersecurity incident response;
• a summary of previous cybersecurity assessment reports.

2. Put cybersecurity into the request for quotation

Under clause 7.4.2, a request for quotation (RFQ) to a candidate supplier must include three things:

• a formal request to conform to ISO/SAE 21434;
• the expectation that the supplier will take on cybersecurity responsibilities, to be set out in the interface agreement;
• the cybersecurity goals or cybersecurity requirements relevant to what the supplier is quoting, for example a requirement for message authentication.

In our view this step matters as much to the supplier as to the customer. Cybersecurity work that appears in the RFQ gets priced and staffed. Work that appears after the award turns into a change request.

3. Agree on a cybersecurity interface agreement

Clause 7.4.3 is the heart of supplier management. Customer and supplier must write the split of cybersecurity work into a cybersecurity interface agreement, the one work product clause 7 produces. It has to cover:

• a cybersecurity point of contact on each side;
• which cybersecurity activities each party performs, for example the customer running cybersecurity validation at vehicle level, and who assesses the supplier's work products (a third party, the customer or the supplier);
• joint tailoring of cybersecurity activities, if any;
• the information and work products to be shared, such as how vulnerabilities and other findings are exchanged, how changes are communicated (including when the threat analysis and risk assessment, or TARA, gets redone) and which requirements management tools both sides use;
• milestones for the shared work;
• when cybersecurity support for the item or component ends.

The standard recommends agreeing on it before the shared work starts and recording responsibilities in a responsibility assignment matrix. Its Annex C gives an example template that assigns each work product a RASIC role for each side (responsible, accountable, supporting, informed, consulted) and an agreed confidentiality level, from "highly confidential" (only the organization that created it can see it) to "public."

Two more rules sit next to the agreement. When a vulnerability needs to be managed, customer and supplier must agree on the actions and on who owns them. And when a requirement is unclear, not feasible, or conflicts with another requirement, including requirements from other engineering disciplines, each side must tell the other so the right decision gets made.

Supplier management continues after the contract is signed

The interface agreement also defines when cybersecurity support ends; until then, ISO/SAE 21434 expects every vulnerability to be handled one of two ways: its risk is assessed and treated so that no unreasonable risk remains, or it is removed with an available fix, such as a patch for open-source software. The standard notes that vulnerability information, like knowledge of attack paths, can be shared between customer and supplier, which is what the agreement's information-sharing section is for. Clause 8 covers this ongoing work, and we walk through it in Exploring Continual Automotive Cybersecurity Activities.

How we would make supplier management work in practice

The standard says what has to exist. These are the habits we think make it hold up.

• Match scrutiny to risk. Spend the deepest review on suppliers whose components your TARA rates highest. A supplier of a telematics unit and a supplier of a simple sensor do not need the same depth of capability review.
• Write the vulnerability path before you need it. Name who tells whom, through which channel and how quickly. When a weakness in a Tier 2 part affects a Tier 1 system and the vehicle above it, ownership of the fix should already be on paper. We proposed one way to share that risk in Collaborative Risk-Sharing in Automotive Cybersecurity.
• Help suppliers close gaps, not only grade them. When a capability check finds a gap, the customer can do the work on the supplier's behalf or ask the supplier to close it. Working on it together usually serves both sides and strengthens the supplier's own chain.

Get a second opinion on a supplier's cybersecurity work

We have done nearly 400 TARAs for automakers and suppliers at every tier, in automotive, agriculture and robotics, so we see supplier work from both sides of the interface agreement. If a supplier's TARA or interface agreement just landed on your desk and you want to know whether it holds up, tell us about it and we will talk it through with you.