To automate Section 889 supply chain risk management (SCRM) documentation in subcontractor-heavy proposals, prime contractors need a governed supplier compliance register that captures each subcontractor's 889 attestation, tier, product category, evidence link, owner, and expiration date, then validates that data against prohibited-equipment lists and exclusion orders before the representation is signed. The failure most primes make is collecting attestations by email at the last minute and never revalidating them, which pushes discovery of prohibited telecom equipment into a post-award audit instead of proposal review.
This matters because the Section 889 representation you sign flows down to every subcontractor and sub-tier vendor, and a single covered device deep in your supply chain can trigger corrective action, cure notices, or worse after award. The fix is architectural: build the validation into a repeatable proposal artifact so no one signs a representation they cannot defend.
Here is the governance model that catches these problems while you can still fix them.
The Post-Award Surprise That Should Have Been Caught at Proposal Time
A prime I worked with won a mid-size IT services contract. During capture, they collected Section 889 attestations from their four named subcontractors, signed the representation in SAM.gov, and moved on. Eight months into performance, a routine supply chain review found that one subcontractor was running video surveillance on gear from a covered manufacturer at a client site. That equipment sat two tiers down, purchased through a reseller nobody had asked about.
The prime had a signed attestation on file. It said the subcontractor did not use covered telecommunications equipment. It was wrong, and the prime had no evidence they had done anything beyond taking the sub at its word.
This is the pattern. Manual email-chain attestation collection breaks the moment you scale past a handful of vendors. A proposal with three named subs might touch fifteen sub-tier suppliers once you count resellers, integrators, and OEMs. Someone in BD forwards a PDF attestation form, chases signatures for two weeks, drops the returned files into a shared drive, and never looks at them again. Nobody cross-checks the products against the FCC covered list. Nobody records who owns each attestation or when it expires.
The core thesis is simple. SCRM validation has to happen before the representation is signed, not during a post-award audit. The representation is a statement of fact you are making to the government. If you cannot back it with dated, owner-assigned evidence at the moment you sign, you are betting your contract on hope. The rest of this article shows how to convert that scramble into a governed workflow that produces defensible evidence every time.
What Section 889, the SECURE Technology Act, and SBOM Mandates Actually Require
Start with the two halves of Section 889 of the FY2019 NDAA, because primes routinely conflate them.
Part A prohibits the government from procuring covered telecommunications equipment or services (from entities such as Huawei, ZTE, Hytera, Hikvision, and Dahua) as a substantial or essential component of any system. Part B prohibits the government from contracting with any entity that uses such equipment or services, regardless of whether it touches the federal contract [1]. Part B is the one that surprises people, because it reaches into your internal operations and your subcontractors' operations, not just what you deliver.
The flow-down obligation is the practical consequence. The prime represents compliance, and that representation depends on every subcontractor being clean too. FAR 52.204-25 carries the prohibition and the flow-down language [2]. If a tier-2 vendor uses covered gear, your Part B representation is inaccurate even though you never touched the equipment.
The SECURE Technology Act created the Federal Acquisition Security Council (FASC), which can issue exclusion and removal orders against specific sources or products [3]. This changes supplier eligibility mid-pursuit. A supplier you cleared during teaming can land on an exclusion order weeks before submission, and your register has to catch that change rather than relying on a stale one-time check.
Software transparency mandates extend SCRM past hardware. Executive Order 14028 directed agencies toward Software Bill of Materials (SBOM) expectations so buyers can see component provenance in the code they acquire [4]. For proposals that deliver software, SCRM now means tracking where code components come from, not only where devices come from.
Translate each requirement into a proposal decision:
- Section 889 Part A: Represent that no covered equipment is a component of your delivered solution. Owner: solution architect. What breaks the bid: any covered component in the technical stack.
- Section 889 Part B: Represent that neither you nor your subs use covered equipment. Owner: SCRM lead. What breaks the bid: an unverified or expired subcontractor attestation.
- FASC exclusion orders: Confirm no named supplier appears on an active order. Owner: procurement. What breaks the bid: a matched supplier with no substitution.
- SBOM expectations: Provide component provenance for delivered software. Owner: engineering lead. What breaks the bid: a component with unknown or prohibited origin.
Why Your Subcontractor Attestations Are a Liability
An attestation you cannot verify is worse than no attestation, because it creates a paper record of diligence you did not actually perform. The common failure modes:
- Expired attestations collected during a prior pursuit and reused without a fresh signature or date check.
- Missing tier-2 coverage where the subcontractor attests for itself but never surveys its own resellers and OEMs.
- Unsigned or draft reps that sit in the shared drive as placeholders and get treated as final.
- Vendors added after teaming who join the delivery plan during proposal refinement and never receive an attestation request at all.
The defensibility gap is the real problem. When a contracting officer or an inspector general asks how you validated your Part B representation, "we emailed a form and they sent it back" is not a diligence process. You need dated, owner-assigned evidence that shows what you checked, when, and against which lists.
| Dimension | Manual email collection | Governed supplier register |
|---|---|---|
| Accuracy | Attestations taken at face value, no product cross-check | Products validated against FCC covered list and FASC orders |
| Freshness | No expiration tracking, stale reps reused across bids | Expiration dates trigger automatic re-collection |
| Tier coverage | Prime-to-sub only, sub-tiers invisible | Roll-up from every sub-tier into the prime representation |
| Audit trail | Files in a shared drive, no dated actions | Timestamped evidence with assigned owner per row |
| Change response | New vendors slip through unrepresented | Adding a supplier triggers a validation gate |
The table makes the choice obvious. Manual collection produces documents; a governed register produces evidence. Only one of those defends a representation.
The Governance Architecture: A Supplier Compliance Register
The center of a working SCRM program is a single register with a defined schema. Every subcontractor and sub-tier supplier is a row, and every row carries the fields you need to defend a representation.
At minimum, the register schema includes:
- Supplier name and unique identifier (CAGE or DUNS where available)
- Tier (prime, sub, sub-tier reseller, OEM)
- Product or service category (hardware, telecom, software, services)
- Section 889 status (clear, flagged, pending, excluded)
- Evidence link (the signed attestation, SBOM reference, or exclusion check)
- Owner (the named person accountable for that row)
- Expiration date (when the evidence goes stale and re-collection triggers)
Each subcontractor's rows roll up into the prime's proposal-level representation. If any sub-tier row is flagged, pending, or excluded, the roll-up shows the representation as not ready. The prime cannot sign a green representation while a red row exists three levels down. This is the mechanism that would have caught the surveillance gear in the opening story: the tier-2 reseller would have been a row, and its product category would have flagged for a covered-manufacturer check.
Validation gates enforce the discipline. Three gates matter most:
- Prohibited equipment gate: any product category matching covered telecom triggers a mandatory cross-check against the FCC covered list before the row can go green.
- Stale evidence gate: any attestation past its expiration date reverts to pending and routes back to its owner.
- Unassigned owner gate: no row can reach green without a named owner, because unowned evidence is nobody's responsibility.
This register connects directly to your compliance matrix automation, where each SCRM requirement becomes a tracked row with owner, evidence, and status rather than a loose commitment.
Key Statistics
$4.88M [5]
Average cost of a data breach in 2024, with supply chain compromise among the costliest vectors
15% [5]
Share of breaches involving a third-party or supply chain compromise in 2024
183 days [6]
Average time to identify a supply chain attack, far longer than other breach types
54% [7]
Share of organizations reporting a software supply chain attack in the prior 12 months
Data Validation Workflows That Catch Problems Before You Sign
The register is only as good as the workflow that keeps it current. A working validation pipeline runs in four stages.
Intake. When a subcontractor joins the delivery plan, the system creates rows for that sub and prompts for its sub-tier suppliers. The attestation request goes out with a defined return date, not an open-ended "when you get a chance."
Automated cross-check. Returned attestations are checked against the FCC covered equipment list and active FASC exclusion orders. A product category flagged as telecom triggers a manual review rather than auto-clearing. This is the step manual processes skip entirely.
Owner routing. Any flagged or pending row routes to its named owner with a specific action, such as "confirm reseller OEM source" or "collect updated attestation." The owner sees the row, the evidence gap, and the deadline.
Sign-off. The representation cannot be signed until the roll-up is fully green. This is the gate that matters.
Freshness rules prevent stale reuse. Set an expiration window (many teams use six months for active pursuits) so any attestation older than that window reverts to pending and re-collects. Change triggers matter just as much: adding a subcontractor during proposal refinement automatically creates unvalidated rows, which turn the roll-up yellow until they are cleared.
Here is what a single SCRM row looks like when mapped like a compliance matrix entry:
| Requirement | Evidence | Owner | Status | Next action |
|---|---|---|---|---|
| 889 Part B, Sub A | Signed attestation, 2026-01 | SCRM lead | Green | Revalidate at 6-month mark |
| 889 Part B, Sub A reseller | Pending survey | Procurement | Yellow | Collect OEM source by Fri |
| FASC exclusion check, all subs | Cross-check log | Compliance | Green | Re-run before submission |
| SBOM, delivered app | Component list draft | Engineering lead | Yellow | Resolve unknown component |
The One Gate That Prevents Most 889 Surprises
Block representation sign-off until every tier is green. Not the top-level subs. Every tier, including resellers and OEMs the subs surveyed. Most Section 889 post-award surprises trace to a sub-tier row that was never created or never checked. If your workflow lets someone sign while a single row sits yellow, you have a documentation process, not a control.
Building the SCRM Documentation Packet Evaluators Trust
Evaluators do not want your reassurance; they want artifacts. A defensible SCRM documentation packet has four parts.
The register export shows every supplier, tier, status, owner, and evidence link in one place. It demonstrates that you tracked the whole supply chain, not just your named subs. The attestation evidence provides the signed, dated documents behind each green row. SBOM references cover software provenance where you deliver code. A narrative diligence statement ties it together, explaining your process, your validation gates, and how you handle changes and expirations.
Rebuilding this packet from scratch for every pursuit is where teams lose weeks. Most of your suppliers appear across multiple bids, so their attestations and register rows should carry forward. A content reuse library lets you reassemble the packet across pursuits, pulling the current attestation for a supplier you have already vetted rather than re-collecting it, while the expiration rules make sure you never reuse something stale.
This is where Projectory ties the SCRM evidence directly to the compliance matrix. When a supplier's attestation expires or a new FASC order lands, the linked matrix row flips status, and the packet reflects the change without a manual rebuild. The packet stays current across submissions because the evidence and the matrix are the same source of truth, not two copies that drift apart.
Frequently Asked Questions
Does Section 889 flow down to subcontractors? Yes. The prohibition in FAR 52.204-25 flows down, and your representation depends on subcontractor and sub-tier compliance. A covered product two tiers down can make your Part B representation inaccurate [2].
How often should subcontractor attestations be revalidated? Set an expiration window and re-collect when it passes. Many teams use six months for active pursuits and revalidate whenever a new supplier is added or a FASC exclusion order is issued.
What is the difference between Part A and Part B? Part A prohibits the government from buying covered equipment as a system component. Part B prohibits contracting with any entity that uses covered equipment, even outside the federal contract [1].
Do SBOM requirements apply to hardware-only proposals? SBOM expectations apply to delivered software. If your solution includes no software you deliver, SBOM tracking is not the priority, but hardware SCRM under 889 still applies fully [4].
Your 30-Day SCRM Governance Rollout
Start narrow and prove the model before you scale it.
Week 1: Build a supplier compliance register for your top three active pursuits. List every subcontractor and every sub-tier supplier you can identify, and assign an owner to each row. Do not wait for a perfect schema; the seven fields above are enough.
Week 2: Run the automated cross-checks. Match every telecom or hardware product against the FCC covered list, and check every supplier against active FASC exclusion orders. Flag what needs review.
Week 3: Close the gaps. Route flagged and pending rows to owners with deadlines, collect missing attestations, and confirm sub-tier sources.
Week 4: Set your gates and expiration rules, then generate a documentation packet from the register.
The metric to track from day one: percentage of subcontractor evidence that is current and owner-assigned. If that number is below 100 percent when you sign a representation, you have identified exactly the exposure that turned into a post-award surprise in the opening story. That prime signed a green representation over a red tier-2 row nobody had created. A governed register would have kept the roll-up yellow, blocked sign-off, and forced the reseller question before the bid went out. That is the difference between a document and a control.
References
- [1]U.S. Congress, "John S. McCain National Defense Authorization Act for Fiscal Year 2019, Section 889," 2018. https://www.congress.gov/bill/115th-congress/house-bill/5515/text
- [2]Acquisition.gov, "FAR 52.204-25 Prohibition on Contracting for Certain Telecommunications and Video Surveillance Services or Equipment," 2024. https://www.acquisition.gov/far/52.204-25
- [3]Cybersecurity and Infrastructure Security Agency, "Federal Acquisition Security Council (FASC) and the SECURE Technology Act," 2024. https://www.cisa.gov/resources-tools/programs/federal-acquisition-security-council-fasc
- [4]The White House, "Executive Order 14028 on Improving the Nation's Cybersecurity," 2021. https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
- [5]IBM Security, "Cost of a Data Breach Report 2024," 2024. https://www.ibm.com/reports/data-breach
- [6]Ponemon Institute and IBM, "Cost of a Data Breach Report 2024: Breach Lifecycle," 2024. https://www.ibm.com/reports/data-breach
- [7]Anchore, "2024 Software Supply Chain Security Report," 2024. https://anchore.com/software-supply-chain-security-report/