The "Developed Using" Clause: DHS Bars DeepSeek From Civilian Federal Systems and Puts Open-Weight Lineage on Trial

The most consequential sentence in American AI procurement this month is six words long and undefined. On October 20, 2026, the Department of Homeland Security published Exclusion and Removal Order #2026-01 under the Federal Acquisition Supply Chain Security Act (FASCSA). It is the first FASCSA order DHS has ever issued, and the first such order to apply across the entire federal civilian executive branch rather than a single department or the intelligence community. It excludes Hangzhou DeepSeek Artificial Intelligence Co., Ltd., its affiliates, and their products from federal procurement — and requires agencies to remove not only DeepSeek’s own offerings but also “third-party products and services developed using DeepSeek implementations” from agency IT systems.

That derivative clause is the part vendors should be reading twice. The order never defines what a “DeepSeek implementation” is, and CISA had published no implementing guidance on the “developed using” standard when the order became public. In an industry that distributes capability as downloadable weights and trains new models on outputs of old ones, an undefined ancestry rule is not a footnote. It is the whole compliance problem.

What the Order Actually Says

The order, signed by Secretary Markwayne Mullin, rests on familiar national-security reasoning: DeepSeek’s servers sit in the People’s Republic of China, where law gives state security functions broad authority over private infrastructure; hosted services collect personal data and can fingerprint users; prompts from federal employees or contractors could transfer sensitive material. The order also asserts that “the models themselves may contain malware or other security vulnerabilities,” citing a February 2025 mobile-app vulnerability assessment — evidence about an iOS application, not about model weights.

Operationally, agencies must do two things. First, exclude DeepSeek, its affiliates, and their products from procurements, including approved product lists, service-provider equipment lists, and e-commerce channels. Second, remove covered products — including third-party implementations — from civilian agency IT systems immediately, unless the agency requests an exception. Exception requests were due within 60 days of the July 24 signature, a deadline that expired roughly four weeks before the order appeared in the Federal Register. As a result, vendors have no exception route under the order itself, though contractors may disclose and request a waiver under FAR 52.204-30 when the clause is added to a contract by modification.

There is also a scoping wrinkle that will occupy contracting officers for months: the Federal Register notice names “Hangzhou DeepSeek Artificial Intelligence Co., Ltd.,” while the signed order names “Hangzhou DeepSeek Artificial Intelligence Basic Technology Research Co., Ltd.” and its footnotes refer to “DeepSeek AG.” Affiliate status under 48 CFR 2.101 turns on control relationships that are hard to establish for a privately held PRC company. These inconsistencies are unlikely to narrow the order’s practical reach, but they do mean vendors should document their interpretive choices rather than assume ambiguity buys time.

Why Open Weights Make This Order Different

FASCSA has been used against hardware and software vendors before — Acronis in 2025, and a Department of War designation of Anthropic in March 2026 that the D.C. Circuit upheld in September, reading “supply-chain risk” broadly enough that a model developer’s training methodology could constrain agency operations even without post-deployment access. But DeepSeek is a different kind of target, because its technology escapes the container that traditional export and procurement controls assume.

DeepSeek publishes models such as R1 under the MIT license, which expressly permits commercial use, modification, and derivative works — and the model card names distillation for training other models as a permitted use. DeepSeek itself shipped six dense distills built on Qwen 2.5 and Llama 3 base models fine-tuned on R1-generated reasoning data. As of late October 2026, the deepseek-ai organization on Hugging Face lists more than 100 public repositories, and Hugging Face metadata records more than 500 community models that declare DeepSeek-R1 alone as their base model — fine-tunes, adapters, quantizations, merges. NIST’s Center for AI Standards and Innovation reported in September 2025 that downloads of DeepSeek models had risen nearly 1,000% since January.

A procurement rule built for named vendors now has to reason about a supply chain where the “product” is a weight file that anyone can copy, quantize, rename, and rebrand.

Mapping the Clause: Where the Risk Actually Sits

The Cloud Security Alliance’s rapid analysis published the day after the order is the most useful public attempt to scope the clause. Its central insight is that the dependency patterns split into two very different problems — an inventory problem and an evidentiary problem.

The inventory problem is tractable. Whether a product calls DeepSeek’s API, self-hosts DeepSeek weights on U.S. cloud GPUs, ships a fine-tune or LoRA adapter, or bundles a DeepSeek-published distill can usually be established from network egress logs, API keys, model inventories, weight hashes, and base_model metadata. Runtime AI inventories and SBOM-style tooling can answer these questions today, at least where suppliers cooperate and model cards are intact.

The evidentiary problem is not tractable with current tooling. A vendor whose in-house model was trained partly on DeepSeek-generated synthetic data, or whose evaluation set was built with DeepSeek outputs, or whose product code was written with a DeepSeek-backed coding assistant, generally cannot reconstruct that lineage months later. And under a literal reading of “developed using,” all three could plausibly be in scope. Reimplementing published architectural ideas — mixture-of-experts routing, GRPO-style reinforcement learning — is unlikely to be covered, because those are ideas rather than implementations. But the line between “used an idea” and “used an implementation” is exactly the kind of question that a certification regime forces someone to answer.

That asymmetry matters more than any single vendor dispute. A company asked to attest that its product was not “developed using DeepSeek implementations” may be unable to do so honestly, not because it is hiding something, but because nobody kept the records. The D.C. Circuit’s willingness to treat training methodology as a supply-chain risk in the Anthropic case suggests this class of development-time question will not be dismissed as out of scope.

What Contractors Are Legally Obligated to Do — and What Customers Will Ask Anyway

FAR 52.204-30, the contractor-facing FASCSA clause, is narrower than the anxiety it is generating. Where the clause is in a contract, it requires contractors to check SAM.gov for applicable FASCSA orders, report covered articles they identify within three business days, and flow the clause down to subcontractors. The formal duty is a “reasonable inquiry” into information already in the contractor’s possession — not a forensic reconstruction of every model that touched every artifact in the company’s history.

In practice, agency customers are already asking for more: blanket attestations that no DeepSeek-derived technology contributed to a product, sometimes with indemnities attached. Vendors face a classic compliance-gradient problem. Refusing to attest looks evasive; attesting confidently looks dishonest; attesting with caveats invites procurement friction. The defensible middle path is documentary: publish a model lineage statement, record which base models and training-data sources were used, keep hashes for distributed weights, and clearly separate “we can prove this” from “we have no record of this.”

Beyond Federal Procurement: The Template Problem

The order’s legal scope is federal civilian agencies. Its practical scope is larger, for two reasons.

First, the order’s own logic travels. Regulated enterprises — financial services, healthcare, defense-adjacent suppliers, critical infrastructure — face the same data-flow and model-integrity questions, and their auditors read federal supply-chain orders as de facto standards. A bank’s third-party risk team asking whether a vendor’s model was “developed using” a PRC-origin implementation is not making a legal argument about FASCSA; it is making a risk argument the order has now legitimized.

Second, the “developed using” standard is likely to become a template. If it survives legal challenge and acquires CISA guidance, the same structure can be pointed at other model families, other jurisdictions, and other dependency patterns. The EU has its own supply-chain instincts; allied governments have watched the Anthropic designation survive appeal. The industry should expect provenance attestation to become a standard procurement artifact, in the way SOC 2 reports did — not because every buyer is bound by FASCSA, but because buyers converge on the most legible compliance format available.

The Uncomfortable Lesson for the Open-Weight Ecosystem

There is a tension the order does not resolve. The same openness that makes DeepSeek models widely downloaded makes them widely auditable — weights can be inspected, hashes verified, and deployment inventories built. Closed APIs are harder to audit in principle but easier to ban in practice: you exclude one endpoint and the product stops working. Open weights invert that. Prohibition is difficult, attribution is hard, and the compliance burden lands on every downstream integrator who ever touched the family.

That is why the order is likely to accelerate two trends rather than one. The first is provenance infrastructure: model bills of materials, signed weight manifests, training-data lineage records, and vendor disclosure standards. The second is jurisdictional segmentation of the open-weight ecosystem, where labs publish models under terms designed to be acceptable to specific procurement regimes, and enterprises maintain separate approved-model inventories per market.

DeepSeek’s own commercial trajectory — record funding, a reported billion-dollar run rate, an IPO path — has so far been insulated from Western procurement restrictions, because its revenue base is overwhelmingly domestic and its model distribution is global and license-permissive. The FASCSA order does not change that arithmetic directly. What it changes is the ambient risk premium attached to DeepSeek lineage everywhere else: in vendor questionnaires, in insurance underwriting, in enterprise model approval boards.

The six undefined words in Order #2026-01 will be litigated, clarified, and copied. In the meantime, the practical advice is unglamorous and urgent: if you ship an AI product to regulated buyers, start writing down what your model was built from. The compliance question has already arrived; the record-keeping has not caught up.