What signed software updates establish for a customer

A signed update helps a customer establish where a software package came from and whether its signed contents changed. It does not establish that the release meets the customer's functional requirements, is suitable for every installed configuration or contains no defects. Those questions need their own evidence.

For a supplier, the phrase “signed updates” therefore needs a concrete meaning in the offer. What is signed, who is responsible for signing it, how does the customer receive the associated verification information and who supports the product when that process changes? These are product-lifecycle questions with implications for delivery and continuing support.

Separate authenticity from permission to change

NIST's 2018 platform-firmware guidance, SP 800-193, makes a useful distinction between authenticating an update and authorising its application. Authenticity concerns the source and integrity of an image; authorisation concerns permission to perform the update. Its framework also considers protection, detection and recovery, rather than treating an update signature as the whole resilience story.

That distinction carries into a commercial software purchase. A customer can accept that a package is an authentic supplier release while still requiring internal approval to introduce it into a particular service. The supplier's release authority and the customer's change authority should both be visible in the delivery model.

Consider a hypothetical company selling an equipment-maintenance application to several organisations. One customer buys a fully managed service. Another installs the same product family within its own environment and controls its update schedule. A common signing process may support both offers, but the responsibility for approving and completing the change differs. The proposal should make that difference understandable.

State exactly what the signature covers

A delivered product may include an application package, supporting utilities, configuration material and documentation. The customer should be able to identify which parts fall within the supplier's integrity-verification claim. A statement about one executable should not acquire the apparent scope of a statement about every file delivered alongside it.

The purchasing discussion can remain straightforward. Ask the supplier to identify the release package and the evidence used to associate it with the supplier's approved release. Then ask how separately delivered components are documented. The objective is an intelligible product boundary, not a request for the vendor's sensitive signing infrastructure.

A release record should also distinguish a production product from a demonstration or evaluation build. If an evaluation moves into a paid deployment, the customer needs to know which supported package it is accepting and what changes between the two. Carrying a demonstration identifier into the contract can create ambiguity even when both packages were authentically produced by the vendor.

Our guide to SBOM product coverage addresses the related question of component identity. The inventory and integrity evidence should point to the same release. Otherwise the customer may hold two valid documents that describe different software.

Make verification information part of delivery

The 2022 SSDF version 1.1 publication includes a practice on making release-integrity information available to software acquirers. Its examples include code signing and periodic review of certificate renewal, rotation, revocation and protection. These are continuing process considerations, rather than a one-time claim that a product supports signatures.

Commercially, the buyer needs a supported way to obtain and use the relevant information. A supplier should explain the intended customer experience at handover and during later updates. The acceptance record can identify the delivered release, the supporting verification evidence and the role responsible for retaining that record.

A product sold through a distributor needs the same clarity. The customer should understand whether the distributor merely transfers the supplier's package, repackages it under an agreed process or supplies an additional integration layer. Each model can be legitimate, but the origin and scope of the assurances should remain visible through the chain.

If the customer uses an environment with restricted external connectivity, the proposal should explain how the ordinary supported delivery process applies there. That is a matter for documented product support and customer approval. A purchasing guide need not prescribe technical workarounds to identify an unresolved commercial dependency.

Ask how the service handles lifecycle changes

The organisation responsible for signing can change its processes, renew credentials or transfer product ownership. Customers may remain on supported releases throughout those changes. The support offer should explain how the vendor communicates relevant transitions and preserves a reliable relationship between older products and their release evidence.

A credible answer identifies a responsible product function and a communication route. It does not require the supplier to disclose private keys, detailed access controls or internal recovery procedures. The customer needs assurance that a foreseeable change in the vendor's lifecycle will be managed without leaving the supported product in an undocumented state.

The same applies to exceptional events affecting trust in previously issued material. The supplier should be able to explain, at an organisational level, how customers would learn that an earlier assurance needs reconsideration and where updated guidance would appear. That communication obligation belongs alongside the vendor's vulnerability-disclosure and support process.

The cost of maintaining this capability is part of product support. A low initial licence price can obscure a weak continuing offer if the vendor treats every change in the delivery process as bespoke professional services. Buyers should compare the supported experience over the intended product lifetime.

Keep product validation as a separate acceptance decision

An authentic release can still introduce an unwanted functional change or fail a customer's compatibility requirement. The acceptance process should therefore connect integrity evidence to the ordinary release notes, supported-configuration statement and product-validation information relevant to the purchase.

For the maintenance-application example, a new release might alter an export used by the customer's finance system. Establishing the package's origin does not establish that the downstream workflow remains compatible. The customer needs a clear description of the changed interface and an agreed route for evaluating the supported integration.

A supplier can make this distinction useful in its sales material. Instead of presenting one security feature as a broad quality guarantee, it can show how release identity, integrity evidence, change documentation and support work together. That gives the buyer several concrete claims to assess and reduces the chance of misunderstanding what a single feature establishes.

The buying team should also avoid turning a successful demonstration of one update into a promise covering every future release. The continuing commitment concerns the process, documentation and supported product boundary. Specific future changes may need their own evaluation when the details are known.

Define the supportable end state

After an update, the customer should know which supported release it has, what evidence accompanied it and who owns any unresolved issue. If a change is deferred, the customer should understand the support status of the existing release and the information needed for a later decision. Both outcomes should be recorded accurately.

A product's end-of-support plan belongs in this discussion because authenticity evidence can outlast active engineering support. An older package remaining verifiably attributable to a supplier does not imply that the supplier will continue maintaining it. The purchase terms should state those responsibilities separately.

The commercial strength of signed updates lies in dependable provenance and an organised delivery lifecycle. Suppliers can demonstrate that strength by defining the signed scope, making verification information usable and maintaining the customer relationship through change. Buyers can then combine that evidence with compatibility and product-quality information to reach a properly bounded acceptance decision.