Safeguard
Regulatory Compliance

FCC and CISA guidance on telecom software supply chain se...

FCC telecom software supply chain guidance now overlaps with the Covered List and CISA telecom advisories. Here's what carriers must actually track.

Marina Petrov
Compliance Analyst
7 min read

In June 2024, the FCC opened a formal inquiry into supply chain risks in telecom software and cloud services, extending years of hardware-focused scrutiny into the code, firmware, and third-party libraries that run networks. If your compliance team has been tracking the Covered List but not the software layer, you're already behind. FCC telecom software supply chain guidance now sits alongside CISA telecom advisory bulletins as the two references carriers, equipment vendors, and managed service providers need to build a working compliance program. This matters because the rules are no longer theoretical: the FCC has denied equipment authorizations, the Secure and Trusted Communications Networks Act created a $1.9 billion reimbursement program tied to rip-and-replace deadlines, and CISA has issued specific advisories naming exploited telecom software. Below, we break down what's actually required, who it applies to, and how to operationalize it.

What does the FCC's telecom software supply chain guidance actually require?

The FCC's guidance requires telecom carriers and equipment makers to identify, document, and mitigate supply chain risk across both hardware and the software that runs on it, extending obligations that used to apply mostly to physical gear. This started with the 2019 Supply Chain Order banning USF funds from purchasing "covered" equipment, but the agency's 2024 Notice of Inquiry (WC Docket No. 24-152) explicitly asked how software, firmware update mechanisms, and cloud-hosted network functions should be assessed for the same national security risks. The FCC has also required equipment authorization applicants, since 2021, to certify that their gear isn't on the Covered List, and it can revoke authorizations retroactively — it did exactly that in 2022 for several Chinese-made devices already in the field. For carriers, the practical requirement is a documented process for vetting software provenance, tracking components back to their origin, and being able to answer, on demand, whether any given build includes code, libraries, or update channels tied to a listed entity.

What is the Covered List and who has to check against it?

The Covered List — sometimes referred to informally as the covered equipment list — is the FCC's published roster of communications equipment and services deemed a national security threat, and any company receiving federal USF subsidies or seeking equipment authorization must check its supply chain against it. Maintained by the Public Safety and Homeland Security Bureau under the 2019 Supply Chain Order, the list currently names companies including Huawei, ZTE, Hytera, Hikvision, Dahua, and China Mobile, China Telecom, and China Unicom's U.S. subsidiaries. The check isn't limited to buying a labeled box: because software is embedded, white-labeled, and resold across OEM relationships, a carrier can end up running Covered List firmware or chipsets without knowing it, particularly in edge devices, small-cell radios, and video surveillance systems bundled into larger contracts. That's the gap regulators are now targeting — the list was built for procurement decisions, but enforcement increasingly depends on being able to trace what's actually running in production, not just what was ordered.

How does the Secure and Trusted Communications Networks Act change compliance obligations?

The Secure and Trusted Communications Networks Act, signed in March 2020, turned the Covered List from an FCC policy into federal law and created the "rip-and-replace" reimbursement program that funds carriers removing banned equipment. Congress appropriated $1.9 billion for the program, later topped up with an additional $3.08 billion after the FCC found the initial funding covered only about 40% of documented replacement costs for the roughly 40 small and rural carriers that applied. Reimbursement isn't just for swapping hardware — the Act's implementing rules require applicants to inventory associated software, firmware, and services, and the FCC has pushed back applications that lacked adequate documentation of what was actually being replaced. For any carrier that received rural broadband or USF funding and has Huawei or ZTE gear anywhere in its network, the Act effectively mandates a full software and firmware inventory as a precondition of getting paid, not an optional best practice.

What has CISA said in its telecom advisories, and why now?

CISA's telecom advisories have shifted from general hygiene guidance to specific, named threats following the Salt Typhoon intrusions disclosed in late 2024, in which Chinese state-linked actors compromised systems at AT&T, Verizon, Lumen, and other major carriers by exploiting unpatched network infrastructure software. In December 2024 and again in a joint advisory with the NSA and FBI in 2025, CISA published concrete guidance for carriers: enforce phishing-resistant MFA on network management interfaces, patch edge routers and session border controllers within defined windows, and monitor for unauthorized configuration changes to core routing software — all framed explicitly around supply chain and third-party software risk, not just direct attacks. Every CISA telecom advisory since Salt Typhoon has repeated the same underlying finding: attackers didn't need zero-days, they used known, unpatched vulnerabilities in vendor software that carriers had deprioritized. That's a supply chain visibility failure as much as a patching failure, and it's why CISA's advisories now read alongside FCC rules rather than as a separate compliance track.

How is the FCC coordinating with CISA and other agencies on enforcement?

The FCC and CISA are coordinating through information-sharing agreements and joint public guidance rather than a single unified rule, which means carriers face overlapping but not identical obligations from each agency. The FCC's Public Safety and Homeland Security Bureau consults with the Department of Commerce, the Department of Defense, and the intelligence community before adding entities to the Covered List, and its 2024 Notice of Inquiry specifically cited CISA's software supply chain frameworks — including the Secure Software Development Framework — as models for what telecom-specific guidance might require. In practice, this means a carrier can be fully compliant with FCC equipment certification rules while still failing a CISA-recommended baseline for software patching or SBOM (software bill of materials) maintenance, or vice versa. Compliance teams that treat these as one checklist rather than two overlapping ones are the ones getting caught flat-footed during incident response, because the FCC asks "is this equipment authorized," while CISA asks "is this software currently exploitable."

How Safeguard Helps

Safeguard was built for exactly this gap between "what's on the approved list" and "what's actually running in production." For telecom carriers and equipment vendors navigating FCC telecom software supply chain guidance, Safeguard continuously inventories software components, dependencies, and firmware across your build and deployment pipeline, and cross-references them against the Covered List and known-risk vendor identifiers so you're not relying on a point-in-time procurement questionnaire. When a new CISA telecom advisory names a specific CVE or vendor software package, Safeguard flags every affected build and deployed instance automatically, instead of leaving your team to manually chase down which network elements are exposed. For carriers managing Secure and Trusted Communications Networks Act reimbursement claims, Safeguard generates the software and firmware inventories regulators expect to see attached to rip-and-replace documentation, cutting the manual audit work that has slowed down roughly 40 carriers' applications industry-wide. And because Safeguard tracks provenance down to the component level — not just the vendor label on the box — it catches the white-labeled and OEM-embedded risk that keeps showing up in Covered List enforcement actions. If your compliance program is still built around annual attestations, talk to Safeguard about moving to continuous, evidence-backed supply chain visibility before the next advisory lands.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.