The Department of Homeland Security (DHS) has barred DeepSeek from civilian agency contracts and instructed agencies to remove its products from their systems. This mandate extends to third-party products and services "developed using DeepSeek implementations," likely including tools built on DeepSeek's open-weight models. This detail is crucial for your program. It shifts the focus from simply banning a vendor to examining the origins of the technology: should you screen suppliers, or should you scrutinize what's inside their products?
The Question at Hand
The order was issued under the Federal Acquisition Supply Chain Security Act of 2018. Exclusion and removal orders can affect prime contractors and subcontractors serving federal agencies, and a 2023 Federal Acquisition Regulation update requires contractors to comply.
So, the practical question for supply chain risk managers is this: when a geopolitical designation occurs, should the response be a narrow, entity-based block, or a broader control over AI model origins across your entire vendor base? Both approaches have valid arguments.
The Case for Entity-Based Blocking
Practitioners who support a named-entity approach present a pragmatic case.
It's enforceable. A blocklist tied to a legal entity, such as Hangzhou DeepSeek Artificial Intelligence Co. and its affiliates, provides procurement, legal, and security teams with a clear target. You can incorporate it into contract language, vendor screening, and network controls. There's no debate over whether a product "counts."
It aligns with legal processes. The statute allows the DHS secretary to bar specific technology from civilian systems, and affected companies have 60 days to challenge the decision in the D.C. Circuit. Agencies can request exceptions within 60 days, with CISA providing written approval or denial. This is a defined process with built-in due process. A provenance-based rule would be more challenging to administer.
It matches your team's capacity. Most third-party risk management (TPRM) teams can't inspect model weights. They can, however, verify corporate names, affiliates, and hosting locations. DHS highlighted DeepSeek's servers in China, where Chinese law allows state cyber and intelligence services to access privately held infrastructure. This is a risk you can assess through due diligence on jurisdiction and data flows.
It avoids overreach. A rule that prohibits "any model with foreign training influence" would be impractical. A narrow designation limits collateral damage to legitimate suppliers.
The Case for Provenance-Based Control
The opposing view argues that entity blocking alone doesn't address the real exposure.
The risk is in the artifact, not the letterhead. DHS warned that "the models themselves may contain malware or other security vulnerabilities." If that's the concern, a vendor that fine-tunes an open-weight model and sells it under its own brand carries the same risk. Your contract is with the wrapper; the risk is in the engine.
Managing fourth and Nth parties is complex. Your analytics vendor embeds a copilot. The copilot vendor licenses a model. The model is a DeepSeek derivative. A standard SIG Core response wouldn't reveal this unless you ask directly. Proponents of provenance control argue that without a model-level inventory, you're only complying with the order on paper while the dependency remains.
Designations are reactive. The order came more than a year and a half after the Navy, NASA, and other agencies began blocking DeepSeek's chatbot independently. Texas, New York, and Virginia acted within weeks of each other early in 2025. A program that waits for the next named entity will always lag behind the threat. A provenance requirement, applied to every AI-enabled vendor, doesn't rely on a government list.
Data-egress concerns aren't entity-specific. DHS noted that employees or vendors could transfer sensitive data to China and urged agencies to monitor network traffic for data leaving their environments and to tighten logging. These controls are effective regardless of which vendor is named next.
Where Practitioners Actually Land
Most teams adopt a hybrid approach, and the challenge lies in the details.
First, they treat the designation as a baseline. Entity screening is integrated into vendor intake and continuous monitoring of active arrangements, covering named affiliates and subsidiaries.
Second, they add AI-specific questions to pre-contractual assessments. Which foundation models does the product use? Are they open-weight or hosted? Where does inference occur, and where do prompts and outputs go? Is any component derived from a restricted developer? These questions are not typically found in off-the-shelf questionnaires, so teams append them.
Third, they impose obligations downstream. A sub-outsourcing clause requiring prior notice before a vendor swaps or adds a model provides a trigger point. Termination rights tied to a government exclusion order, and a right to audit that extends to model sourcing, offer a way out when a new designation is issued.
Fourth, they accept imperfect coverage. Few teams can independently verify model lineage. They rely on vendor attestations backed by contractual liability and indemnification, reserving deeper review for criticality classification tiers where the data is sensitive.
Federal contractors face a tougher version of this. Compliance with removal orders isn't optional, and the reach to subcontractors means a gap in your supplier's disclosure becomes your exposure.
Our Take
Entity-based blocking is necessary but not sufficient. You need it because it's the only control with legal backing and because a named designation is the one signal everyone in your organization will act on. But if it's your only control, you've outsourced your threat model to the government's timeline.
The stronger position is to build the model-provenance inventory now, before the next order. Treat AI components like any other critical dependency: ask for the bill of materials, require notice of changes, and map where data flows. ISO 27036's supplier-relationship guidance and your existing risk governance framework provide the structure; the AI-specific questions are the addition.
There's a real tradeoff. Provenance questions add friction to vendor intake, slow procurement, and produce attestations you can't fully verify. Smaller vendors may not know what's inside their own stack. That cost is worth paying for AI-enabled products touching sensitive data, and it's probably not worth paying for low-criticality tools with no data access.
The DeepSeek order draws the line at the vendor and its derivatives. Your program should draw it wider, and sooner.
