An industrial PLC supplier refuses to give any SBOM and offers a security assurance letter — how do you read that?
answer
- the refusal is itself evidence
- ask which refusal it is
- will not, cannot, may not
- a letter carries no components
- compensate around an unenumerable device
basics
~20 sAs information about the supplier. Find out whether they will not or cannot produce one: inability predicts slow advisory answers too. A letter carries no components, so pair it with checkable commitments and compensating controls around the device.
solid answer
~50 sA refusal is evidence in its own right, so first establish which refusal it is. **Will not** is a commercial or legal position and is negotiable — under confidentiality, through a trusted third party, or as a reduced component-and-version list. **Cannot** is a capability finding: a firmware build that cannot enumerate its own inputs usually cannot tell you quickly whether a new advisory touches the product either, and that is the answer you will need at 09:00 one morning. **May not** — their own suppliers forbid disclosure — says the stack is assembled and opaque several layers down. An assurance letter is a promise, not an inventory: it contains no components, so it can never answer `does this product ship that library`. Accept it only alongside checkable commitments — notification within a fixed window, named contacts, patch timelines — and then compensate around the device, because you cannot patch what you cannot enumerate.
go deeper
Know the basic distinction: a letter is a promise about process, while an inventory lists components. Only one of them can answer whether a named library is inside the product.
Explain why a refusal has diagnostic value and what the fallback asks look like — component-and-version list, answer-on-demand within a window, notification commitments — and why each is weaker than the full document.
Demonstrate the whole play: probe which refusal it is, negotiate down the ladder, then design compensating controls around a device you cannot enumerate and get the gap recorded with an owner and a revisit date.
Own the call on single-source safety-critical suppliers where the evidence will not arrive: what residual risk the organisation is accepting, who signs for it, and whether regulatory change makes it worth reopening at renewal.
## Treat the refusal as a finding, not an obstacle When a supplier declines to hand over a component inventory, the interesting output is not the missing document — it is what the refusal reveals about the supplier's engineering and its posture. Senior candidates ask a follow-up question before reaching for a risk register. ## Three refusals that look identical and mean different things **`We will not`** — a commercial or legal position. The vendor believes the component list is competitively sensitive, or is nervous that publishing it invites attackers to shop for known flaws. This is the most negotiable case. Options that often land: delivery under confidentiality with explicit rights for you to store and query it; delivery to a named third party who can answer component queries on your behalf; or a reduced deliverable — third-party components and versions only, with proprietary modules collapsed to a single opaque entry. **`We cannot`** — a capability finding, and the one that should change your risk rating. If a firmware build cannot emit an inventory, the build does not have a reliable record of its own inputs. The consequence is not really the missing file: it is that when an advisory lands on a widely embedded library, this vendor will take weeks to answer *does our product contain it*, because someone will have to go and look. Inability to enumerate predicts slowness to respond, and slowness to respond is the thing that actually hurts you. **`We may not`** — their own upstream suppliers forbid disclosure. This tells you the product is assembled from other vendors' software and their visibility already stops several layers up. It also tells you exactly where to aim a flow-down obligation at the next renewal. ## What an assurance letter is, and is not A signed security assurance letter is a **promise about process**, typically: we follow a secure development lifecycle, we monitor advisories, we will notify customers of relevant issues. That has genuine value — it is a signed commitment by a named officer, and it can be held against them. What it structurally cannot do is answer a component question. It contains no components. So when a critical advisory drops on an embedded library, the letter gives you nothing to search; you are back to emailing the vendor and waiting. Never let a letter be scored as an equivalent substitute in a supplier assessment — they answer different questions, and only one of them is machine-readable. ## The ladder of narrower asks When the full document is refused, ask for less rather than nothing. In descending strength: 1. Full inventory per released version, under confidentiality. 2. Third-party components and versions only; proprietary modules opaque. 3. **Answer on demand**: you name a component, they confirm within a fixed window whether the product contains it and at what version. Weaker than an inventory, but checkable — you can test it with a component you already know is in there. 4. Notification commitment: they tell you within a counted window when a published advisory affects the product, with a named contact and a patch timeline. Level 3 is the pragmatic settlement with many device vendors, and it is worth far more than a letter because it has a clock on it. ## Compensating around a device you cannot enumerate With safety-critical industrial equipment, walking away is usually not available: the device is certified, single-sourced and embedded in a physical process, and the asset you are protecting is the safe operation of that process rather than a database. So the control moves off the artifact and into its environment: strict network segmentation with the device unable to reach the internet or general corporate networks, tightly controlled engineering access, monitoring of the traffic it does emit, a tested procedure for taking the process to a safe state, and a patch window negotiated with operations long before you need it. Also price the gap honestly in procurement: record which device families have no component visibility, what compensating controls you are now depending on, who accepted that, and when it gets revisited — normally the next renewal, which is also your next real leverage point. ## The direction the market is moving Regulatory pressure is closing this door for vendors. Regimes such as the EU Cyber Resilience Act place obligations on the manufacturer of a product with digital elements to know its components and to handle vulnerabilities in them. That turns `we cannot produce one` from a negotiating stance into the vendor's own compliance problem, and gives you a legitimate, non-adversarial way to raise the question again rather than filing the letter and moving on.
- What narrower ask often succeeds when a full inventory is refused?Answer-on-demand. You name a component, and the vendor confirms within a fixed window whether the product contains it and at what version. It is weaker than an inventory, but it has a clock on it and you can test it with a component you already know is present. Vendors afraid of exposing their whole stack frequently accept this.
- Why does `cannot` worry you more than `will not`?Because it predicts response time. A build that cannot enumerate its own inputs has no reliable record of them, so when an advisory lands on an embedded library, answering `are we affected` becomes a manual investigation measured in weeks. The missing document is an inconvenience; the missing capability is what leaves you exposed during the window that matters.
- The vendor offers to lodge the document with a trusted third party instead. Useful?Only if the release terms match your need. An arrangement that releases the document solely on vendor insolvency is useless for advisory response, because that question arrives while the vendor is perfectly healthy. It works if the third party can answer component queries on your behalf inside a fixed window, or release the document to your auditors under confidentiality.
saying these in an interview costs you the question
- Treats a signed assurance letter as equivalent to an inventory
- Assumes refusal is always legal caution, never inability
- Accepts a flat no without proposing a narrower, checkable ask
- Records the gap but adds no compensating control
- Rates a device supplier purely on the documents it will sign