SBOM used to sound like something for policy nerds, procurement teams, or very patient security specialists. Not anymore!
Software supply chain risk has moved into the center of cybersecurity, and MSPs are right in the middle of it. They may not manufacture the software their customers rely on, but they evaluate it, deploy it, manage it, update it, and often hold privileged access across many client environments.
That makes software transparency much more than a technical detail. It becomes a question of trust—and the dynamics of trust are changing. Regulators, customers, insurers, and counterparties increasingly want more than just dashboards and green lights. They want evidence. They want to know what is inside the software, how risks are tracked, and whether the right controls can be proven.
That is where the Software Bill of Materials becomes important for MSPs. SBOMs, logs, configurations, vulnerability data, and third-party information are becoming audit artifacts, assurance signals, and the raw material for client-facing proof.
The rise of the Cyber Resilience Act, DORA, PCI DSS requirements, and broader pressure around vendor accountability all point in the same direction: customers will increasingly expect to know where software risk sits, who is responsible for acting on it, and how quickly action can be taken.
That is why we spoke with Dr. Allan Friedman, one of the leading figures behind the global SBOM movement and a key voice in software transparency policy. At MSP GLOBAL 2026, he will bring the conversation down to earth for service providers: what MSPs should demand from vendors, how they can avoid treating SBOMs only as a compliance checkbox, and how they can turn data they already have into value-added attestations their clients can actually use.
SBOM has moved from a specialist supply-chain topic to something every software provider is being asked about. What changed and why should MSPs care now?
Supply chain went from a niche topic to a mainstream IT concern when it became clear that attackers were targeting upstream supply chains and exploiting vulnerabilities buried deep in our dependencies. These attacks often bypass traditional security controls because the malicious or vulnerable code arrives through legitimate applications, updates, and tools, but we have traditionally lacked visibility to identify them before it was too late. Modern organizations don’t build their software from scratch, and neither do their vendors. Instead, they build on open source packages and a host of development and deployment tools. SBOMs allow visibility into risks that are already embedded in deployed software. Fundamentally, it comes down to a very basic proposition: why should I trust software or its provider if they can’t tell me what is in that software?
The Cyber Resilience Act is pushing cybersecurity and software transparency into the regulatory mainstream. Where do MSPs fit in if they don’t manufacture the software, but they select, deploy, manage, and support it?
The CRA explicitly focuses on the manufacturers of digital products, including most software. It may not directly regulate organizations that deploy or manage software, or bring pure software-as-a-service offerings. The good news for security is that the CRA requires commercial software manufacturers and large OSS suppliers to share quite a bit of security information around long term support and vulnerabilities, and these vendors are also expected to maintain and support software through its lifecycle. What does this mean for MSPs? More data about risks, and thus an obligation to use this data to protect their customers. They will have to correlate, prioritize, and orchestrate action based on this data. Success will require building out capabilities to target, automate, and scale.
The CRA fits into a larger global trend of using transparency and data sharing as a catalyst to enable security action. We’ve seen this in sector-specific laws like the financial sector’s DORA and in private standards such as the Payment Card Industry’s Data Security Standard. This can support more effective management, but only if leveraged strategically.
Many MSPs rely on large stacks of third-party tools. What level of SBOM visibility should they realistically demand from vendors, platforms, and clients?
A single SBOM should help an organization understand any potential risk from vulnerable dependencies or third party components in the software to which it belongs. This SBOM should cover the full supply chain, with enough data to capture all third party software, and enough detail to effectively map the dependencies to known risks, particularly vulnerability databases. Key guidance documents, such as the BSI Technical Guidelines from German and international 2026 CISA Minimum Elements, offer clear structures for the quality and type of data needed. MSPs should prioritize obtaining SBOMs for tools critical to delivering customer services, particularly those that handle privileged data. For internally designed and built applications, SBOMs should be generated as part of the development and deployment process. They should also seek out SBOMs for client systems that are critical for their respective business operations.
MSPs have a unique role in managing software risk, however, that goes beyond treating SBOMs as unique, atomic risk management tools. They manage large software ecosystems of their own, with complex webs of dependencies, exposures and value-at-risk through their tools and services. In tracking and managing client systems, they see a full range of systems, and different versions and configurations of these systems inside and across customers. MSPs thus serve as a type of “dependency aggregator.” This can help organizations understand risk concentration. Some open source components, for example, could have a particularly severe “blast radius” that can affect multiple internal systems or customers.
What separates a useful SBOM program from a compliance checkbox or a file nobody ever opens?
SBOMs only matter if they improve decision-making and response. Data shapes intelligence which should drive action. Fortunately, good MSPs have a strong focus on exactly this. The goals should be to integrate SBOM data into existing capabilities and services, and build out strategies to offer new services to create value for customers.
We can break an SBOM program into three parts: generation, management, and consumption. A good program doesn’t just ask for a single SBOM, but builds out the capability to get updated SBOMs for each software update. For internally-generated software, SBOM generation should be an automated part of the development and deployment process. Quality open source tools exist that can be integrated into modern pipelines, while commercial tools offer enterprise-grade features.
An SBOM program will receive SBOMs. Lots of SBOMs. Tracking this data effectively is an often overlooked key to a successful SBOM program. SBOM management tools, either acquired or built, should track SBOMs, including updated SBOMs and versioning. This metadata should be closely mapped to software assets. Without asset context, a pile of SBOMs is just a document repository.
Finally, of course, the SBOM data must be used. While there are many creative uses for supply chain data, the most straightforward is to map the data into existing security functions, such as vulnerability management and incident response. Mapping SBOMs to known vulnerabilities and risks can be accomplished with open source tools, and can be integrated into existing functions for most MSPs. For each of these steps, speed and scale are real differentiators, which means planning for automation and building systems that can integrate across the customer base.
How can MSPs turn SBOMs into a practical service offering: For example in procurement, vulnerability management, incident response, or client risk reporting?
While SBOM startups initially proliferated, businesses soon discovered that customers don’t want to pay for SBOM data. They are, however, increasingly willing to pay for visibility, confidence, and ease of operation. Visibility can address specific customer roles. Executives care about exposure reduction, compliance posture, and how an organization is keeping up with evolving risk trends. The operational team may care about affected assets, remediation prioritization, and unsupported software.
Beyond the most frequent use for vulnerability management, SBOMs can be useful for directly informing procurement decisions for customers. Common questions that an MSP can facilitate include whether and how a potential vendor produces an SBOM and the quality of that data. This data can determine the presence of known risks, but it can also signify supply chain and software quality features such as unsupported or outdated dependencies and even total cost-of-ownership estimates through long term support costs.
One key value-add for SBOM data is to offer informed risk information about specialized software often used by specific types of small-and-medium enterprises such as healthcare applications, manufacturing support software and other specialized services. The relatively small market for these applications mean they may not have publicly-disclosed vulnerabilities found in widely-used vulnerability databases. However, they often use third-party or open source components that will have public vulnerabilities. These are more likely to be exploited in automated hacking tools like ransomware packages or general purpose hacking frameworks like Metasploit. The absence of public vulnerabilities for applications themselves does not mean the absence of risk, and SBOMs can help balance this.
What are the most common mistakes organizations make when they start with SBOMs: too much data, poor tooling, lack of ownership, or failure to connect it to real operational decisions?
From a strategic perspective, organizations should not start by thinking of SBOMs as somehow distinct from the existing security mission. MSPs should take advantage of their existing security skills, practices, and processes, and focus on how SBOMs can be used to enhance these capabilities as a signal for quality, efficiency, and thoroughness. Another strategic mistake is to attempt to do too much, too quickly. Boiling the ocean seldom works. As a program grows, organizations should invest or build out infrastructure for a broad mission, but don’t try to do it for everything all at one. Start with systems and workflows where SBOM data immediately improve operational decisions. As with many types of organizational change, it’s important to have champions inside the organization who can help drive innovation amidst competing priorities, and work to engage other parts of the organization: engineering, customer success, marketing, and the executive team.
Operationally, focus on automation and take advantage of the machine-readable nature of SBOM data. This includes managing the data and aligning it with asset data as much as possible. While the amount of data may seem intimidating at first, proper data management enables flexible and evolving data use without it getting in the way of other activities. For organizations that build software, it’s important to integrate SBOM creation into existing pipelines for native application security. Manual or after-the-fact SBOMs don’t scale, and can quickly become stale.
Finally, too many organizations treat SBOM data as a static property, or a point-in-time inventory. Effective SBOM programs support continuous risk management by turning software transparency into an ongoing operational capability: continuously evaluating exposure, prioritizing remediation, and helping security teams respond quickly as vulnerabilities and threat intelligence evolve.
For an MSP that wants to be CRA-ready before customers start asking difficult questions, what are the first three actions they should take in the next 90 days?
The first step will be to build out the road map, and plan for tool and service integration. Decide where SBOM data can be used operationally. This starts off as a business decision, and should explicitly consider return-on-investment. What is the most straightforward to implement today? What will deliver the most value or potential market upside, but will require resource, coordination, internal engineering, or direct customer engagement.
The second step is to explicitly address the data management piece. How will this be integrated across internal tools, customer data and systems, and environment contexts. This includes how the data will be stored and updated—SBOM data is highly dynamic over time. This will also require a planning component—what future tools or management functions may be ultimately linked to SBOM data and capabilities? As we discussed, this piece is often overlooked, yet will be critical to actually delivering value to customers, across specific reporting needs, asset management realities, and multi-tenant systems.
Last but not least, MSPs should start asking for SBOMs today. This covers both their own systems, and the software and devices on customer networks. MSPs can prioritize which SBOMs they seek by looking for a few things. Which tools are critical for customer support, or where compromise would be the most damaging for customers. Which customer systems have been identified as particularly risky? Which large systems are vital for customer operations, but are built and maintained by smaller vendors who may not have mature vulnerability and risk management processes themselves. Asking is relatively low cost, and you may have more success than individual customers. You may not get them all, but you can’t build a SBOM program without SBOMs.
See Allan Friedman at MSP GLOBAL 2026
Allan Friedman will join the MSP GLOBAL 2026 speaker lineup in PortAventura, Spain, where the MSP community will gather to explore cybersecurity, business growth, service delivery, partnerships, M&A, and the future of managed services.
His message for MSPs is not about paperwork. It is about trust.
If you are responsible for the software your clients rely on, you cannot treat transparency as someone else’s problem. You need to know what is inside the tools you deploy, where the risks sit, and how quickly you can act when something changes. Switched-on MSPs know that in the next era of managed services, software trust will not be assumed—it will have to be proven.
