Telecom is the industry where software supply chain risk has the most concentrated impact and the longest tail. A compromised RAN element does not just affect one company's data; it potentially affects every call, every message, and every emergency service routed through that infrastructure. The 2020 SolarWinds incident put telecoms on notice, the 2024 Salt Typhoon disclosures put them on a deadline, and the regulatory frameworks now in effect for 2026 are turning that deadline into enforceable controls.
This post is for telecom security and risk teams trying to translate the new regulatory expectations into concrete supply chain controls. We will skip the high-level threat narrative and focus on what specifically to change.
What regulatory pressure is actually in effect?
The relevant frameworks for 2026 are the FCC's Covered List and the secure equipment ruling under the Secure Networks Act, ENISA's 5G Toolbox with its annexes on supply chain risk, and CISA's Telecommunications Sector Supply Chain Risk Management guidance updated in late 2025. The FCC's enforcement posture changed materially after Salt Typhoon: orders that were previously framed as advisory now carry concrete compliance timelines and audit expectations.
The practical impact: US-licensed carriers are expected to maintain SBOMs for core network functions, document upstream vendor security postures with refreshed assessments at least annually, and demonstrate continuous monitoring of those vendors against the Covered List. European carriers under the 5G Toolbox have parallel obligations with somewhat different evidentiary formats. Carriers operating in both jurisdictions are running roughly the same control set with two reporting formats, which is the operationally sensible way to handle it.
How do I approach RAN software supply chain?
RAN software is where the supply chain conversation gets most complex. Open RAN architectures introduced the possibility of mixing components from multiple vendors, which improves competitive dynamics but multiplies the supply chain assessment burden. A traditional RAN deployment had one or two software vendors to assess. An Open RAN deployment can have eight or ten across the radio unit, distributed unit, central unit, RIC, and the various xApps and rApps that ride on top.
The control set that holds up: enforce SBOM submission as a procurement requirement for every RAN software component, not just the major elements; run reachability analysis against each SBOM to identify CVEs that actually affect deployed configurations; require signed software bills with verifiable provenance against the SLSA framework; and maintain a continuous monitoring feed for emerging vulnerabilities. Several Tier 1 operators in Europe and North America moved to this control set during 2025 and the operational pattern is now reasonably well understood.
What about OSS/BSS and the back-office stack?
OSS and BSS systems are less glamorous than RAN but they are where most of the actual data and many of the privileged credentials live. The 2024 disclosures around carrier billing system compromises highlighted that attackers know the OSS/BSS stack is the soft underbelly: large, complex, often legacy, and frequently under-monitored relative to its access level.
The control posture for OSS/BSS should mirror what you would apply to any critical enterprise application, but with two telecom-specific additions. First, the customer data flowing through these systems is regulated under CPNI rules in the US and ePrivacy directives in Europe, so a supply chain incident affecting OSS/BSS has a separate regulatory disclosure track from the FCC reporting. Second, integrations with regulatory and law enforcement systems, including CALEA interfaces, create a class of supply chain risk that does not exist in most enterprise environments. Compromise here is not just data loss; it is potential interference with lawful intercept obligations.
How do I handle Chinese-origin equipment under the Covered List?
The FCC Covered List has expanded steadily since 2020 and the 2025 updates broadened the scope to cover more component categories and ownership structures. The compliance question for most US-licensed carriers is no longer "are we using Huawei or ZTE equipment" because the major equipment has been removed under the Secure Networks Act. The 2026 question is "are any of our software vendors using Covered List components in their supply chain", which is a substantially harder question to answer.
The control that works: contractual obligations on every software vendor requiring disclosure of Covered List components in their own supply chain, backed by SBOM evidence and periodic audits. The operational mistake we see most often is treating this as a procurement-only control. Procurement signs the clause and the security team never validates the disclosure. Build the validation into your SBOM ingestion pipeline so it runs automatically on every vendor release, and the control becomes self-enforcing.
What does continuous monitoring look like in practice?
Continuous monitoring is the requirement that most distinguishes telecom supply chain controls from generic enterprise security. The FCC, ENISA, and CISA frameworks all expect that you can answer questions about vendor security posture and component vulnerability exposure on demand, not on an annual reassessment cycle.
In practice this means a vendor inventory that updates with each procurement event, an SBOM repository that ingests new versions automatically, a CVE feed that maps newly published vulnerabilities to your deployed inventory within hours, and a TPRM scoring layer that tracks vendor incident history and patching cadence. The operational shape is roughly the same as a modern application security program, but the inventory scope is larger and the regulatory disclosure timelines are tighter. The carriers we see doing this well treat the monitoring system as critical infrastructure in its own right, with the redundancy and observability budget that implies.
How Safeguard Helps
Safeguard's SBOM pipeline ingests RAN, core network, and OSS/BSS software components in a single repository with automatic version tracking and reachability analysis specific to telecom deployment topologies. Griffin AI correlates emerging CVEs with the FCC Covered List, ENISA risk indicators, and known telecom-targeted threat actor patterns, surfacing the small subset of vulnerabilities that materially change your regulatory posture. TPRM scoring covers the full vendor tree including subcomponents, which is the data telecom procurement teams need to answer Covered List disclosure questions credibly. Policy gates enforce signed-build requirements and SLSA-level provenance on every vendor submission. Continuous monitoring outputs map directly to the evidentiary formats expected by FCC and ENISA audits.