An NDA is optional. The NTIA minimum elements report says suppliers may make SBOM data public or limit it to specific customers, and that if access is restricted the terms must be specified, including how the customer may use the data in its security tools. Clear usage terms matter more than the label.
What the guidance actually says
The NTIA report lists access control as one of the practices an SBOM arrangement should settle. It describes two common positions. Some suppliers, including open source maintainers and those with widely available software, may feel public data serves them best. Others, especially at first, may keep the data confidential and limit access to specific customers or users. The report adds that the terms can be set through licensing, contracts or other existing mechanisms used to define rights around the software.
It does not say an NDA is required. That is a business decision.
Three ways to share
| Approach | Good fit | Watch out for |
|---|---|---|
| Public SBOM | Open source or widely distributed products | Everyone, including attackers, sees your component list |
| Customer only, under existing contract | Commercial product with a signed agreement | The contract must allow loading into the customer's tools |
| Customer only, separate NDA | Request from a party with no contract yet | Slow legal cycles and one off terms |
Most vendors with signed customers use the middle row. The master agreement already covers confidentiality, so an extra NDA adds delay without adding protection.
Terms that matter more than the NDA itself
Write down four things, whatever document carries them.
- Permitted use. The customer may ingest the SBOM into its vulnerability and asset tools. The NTIA report specifically mentions allowances for integrating the data into the user's security tools, so a clause that forbids this defeats the point.
- Onward sharing. State whether the customer may share it with its own auditors, regulators or service providers.
- Updates. Say whether new versions follow each release and how corrections are sent.
- Retention. Say whether old versions must be deleted. Usually they should not be, because customers need history to answer incident questions.
How to decide quickly
Ask three questions. Is the product already public or open source? If yes, public sharing is probably simplest. Does the requester have a contract with you? If yes, point to the confidentiality clause and send. Is the request from a prospect? Share a summary or a sample first, and the full file after signature.
An SBOM lists components and relationships, not your source code. Many teams find the real exposure is smaller than feared, but check the file for internal URLs and private names before any release. A separate post covers which fields can leak internal details.
Quick check
Is it wrong to share an SBOM without an NDA?
No. The NTIA guidance allows public sharing. The decision depends on your product, your contracts and your comfort with exposing the component list.
Can a customer refuse to use the SBOM in their scanner because of our terms?
They may if your terms forbid it, which is why the terms should permit ingestion into the customer's security tools.
Safeguard's SBOM and dependency scanning can produce the file you share, and the free scan is a way to review your own component list first.
Sources
Last reviewed: 19 October 2026.
