Signing keys are part of the vehicle operating model

A software signature is useful only when the organisation controls who can create it and how the receiving system interprets that authority. For vehicle updates, key management therefore extends beyond choosing cryptography. It becomes an operating model involving suppliers, release approvals, protected services and the vehicles that may reconnect long after a key has changed.

Start by separating the decisions involved in an update. Building a package, approving its behaviour, assigning it to vehicles and signing the relevant information are different responsibilities. Combining them without scrutiny can turn one compromised account into broad deployment authority.

Map authority before tools

Uptane defines distinct signing roles for different update metadata. The general management lesson is to make authority explicit: which role can approve which information, and what an attacker could do if that role were compromised. This article's operating questions do not substitute for implementing the standard's technical requirements.

Draw the path from supplier delivery to vehicle acceptance. Identify keys, accounts and approval steps along it. Include delegated authority and shared services. A diagram that ends at the manufacturer's repository is incomplete if vehicles rely on keys or metadata provisioned elsewhere.

Design routine work around custody

Determine where protected keys live and how authorised systems invoke them. Define the records produced when signing occurs, including the identity of the artefact and the reason it was authorised. Investigators need to distinguish an approved release from a package that merely carries a valid signature.

Plan access changes when people or suppliers leave. Routine revocation should not depend on finding an individual who remembers how a signing service was configured. Keep ownership, recovery contacts and documented access procedures attached to each relevant role. Review privileges against actual release responsibilities instead of granting broad rights for convenience.

Rehearse key compromise

An emergency plan should explain how the team detects suspected compromise, pauses affected operations and establishes replacement trust. It needs a route for determining which vehicles can receive updated trust information and which will need another intervention. The technical procedure should be tested in an isolated environment appropriate to the architecture.

Consider vehicles that have been offline throughout the transition. Their return can expose assumptions about metadata history or available recovery material. Retaining enough information to support those vehicles is an operating choice that should be considered alongside storage and security policy, rather than discovered during a customer support incident.

Keep supplier delegation reviewable

Where a supplier has authority over specific components, define its boundaries and the evidence the manufacturer expects with a release. A supplier's internal approval does not automatically settle vehicle-level compatibility. The manufacturer still needs a process for accepting the component into a supported configuration.

Key management should be reviewed with release and service operations, not confined to a security presentation. The business needs to know whether authorised updates can continue during staff changes, system failures and supplier transitions. Good custody protects the fleet while preserving the manufacturer's ability to maintain it throughout its support life.