“When we add a new supplier, what does it actually take to bring their signing into our governance?”

It is a good question because it exposes a gap that many organisations have.

They know they have a PKI. They know suppliers sign firmware, software or other release artefacts. They may even have a certificate policy and a code signing standard.

But supplier onboarding is often much less clear. Who approves the supplier’s signing authority? What are they allowed to sign? How are their keys protected? How are certificates issued, renewed, suspended or revoked? Who watches the signing activity once the supplier is live?

Too often, the answers sit in someone’s head, in a spreadsheet, or in a process document nobody has reviewed since the PKI team changed.

Bringing a supplier into signing governance takes more than issuing a certificate.

Here is what it actually takes.

Step one: Start with scope. Be clear about what the supplier is allowed to sign and under what constraints. Firmware images, bootloader components, application packages, configuration artefacts and diagnostics plugins do not carry the same risk and carry different assurance requirements.

A supplier signing boot loader code sits much closer to the root of trust than one signing a non-critical plugin. The approval route and assurance evidence should reflect that.

As a minimum, you need to know what artefacts the supplier will sign, where those artefacts sit in the product or software lifecycle, and what the signature is used for. Is it there for integrity, authenticity, secure boot, release control, or a combination of these? You also need to know whether the signed component can affect safety, security, service availability or regulatory compliance.

Without that level of detail, “supplier code signing” becomes too broad to manage properly.

Step two: Assess their key management posture through specific questions. Vague assurance is risky here. “We have secure key management” tells you very little.

Ask where private keys are generated, stored and used. Are they held in anHSM, a cloud KMS, a software key store, a CI/CD secret store, or a build server?Are the keys exportable? Who can access them? Is signing manual, automated, or handled through an approved signing service? Are duties separated between developers, release managers and certificate administrators?

The operational details matter as well: certificate renewal, backup, key rotation, incident response, revocation requests, audit logs and access reviews.

You are trying to find out whether their signing practice is a discipline and treated like a security control or an afterthought.

Step three: Policy alignment should happen before you issue, delegate or cross-certify anything. This is where supplier intake often goes wrong. The supplier accepts your code-signing policy, but nobody checks whether their actual process can meet it.

For example, your policy may require keys to be non-exportable and held in certified hardware. Their process may rely on a software key store in a build pipeline. Your policy may require dual control for production signing. Their process may allow one release engineer to trigger signing alone. Your policy may require revocation within a defined time window. Their support model may not be able to meet it. These gaps are control weaknesses.

Before you create the trust relationship, test the supplier’s real process against your requirements. If you accept exceptions, document them, risk-assess them, approve them at the right level and put compensating controls in place.

Step four: The trust relationship also needs to be explicit. If you issue certificates to suppliers, delegate signing authority, or accept signatures from a supplier-controlled CA, document the trust chain properly.That record should cover the supplier identity, approved certificate profiles, permitted signing use cases, certificate validity periods, issuing CA or intermediate CA details, revocation routes, business and technical owners, renewal evidence, and the process for suspension or termination.

This matters because supplier relationships change. Contracts end. Teams reorganise. Build systems move. If nobody owns the trust relationship, old signing permissions can outlive the business need behind them.

Step five: Continuous monitoring after onboarding. Once the supplier is live, signing activity needs to be visible. Signing events should be logged and reviewable. Certificate expiry should feed into your monitoring. Unusual signing patterns should be investigated. Revocation paths should be tested before an incident. Evidence of key protection and access control should be refreshed periodically, not only at onboarding.

A supplier can be competent and trustworthy and still create risk if their signing activity sits outside your visibility.

The cryptography here is usually not the hard part. The hard part is governance: scope, authority, ownership, evidence, monitoring and removal of trust when it is no longer justified.

Multi-supplier signing becomes risky when organisations treat PKI as the control. PKI is the infrastructure. The control is knowing who is allowed to sign what, under which conditions, using which keys, with what evidence, and under whose monitoring.

If a supplier’s signature can move code, firmware or configuration into your environment, then their signing process is already part of your control environment. You need to treat it that way and ensure you can prove that supplier signing is governed from onboarding to retirement.