DeepSeek Federal Order Goes Public: Scope, July Issuance and Third-Party Products

A newly published U.S. federal notice confirms an order excluding DeepSeek from civilian-agency procurement and requiring removal of covered products, including third-party implementations. The underlying order dates to July, making its chronology, scope and exceptions essential to understanding today’s headlines.

The U.S. government’s restrictions on DeepSeek have entered a new public phase. A Department of Homeland Security notice scheduled for the October 20 Federal Register sets out an exclusion and removal order covering federal civilian information technology. Its reach extends beyond a chatbot bearing the DeepSeek name to certain products and services built by other suppliers using DeepSeek implementations.

The distinction between publication and issuance is critical. The signed appendix identifies July 24, 2026 as the original release date of Order 2026-01. The notice was filed for public inspection on October 19 and scheduled for publication on October 20. Reporting it as an order first signed today would give readers the wrong chronology. The official document is available in the Federal Register public-inspection PDF.

Two obligations, with a broader supply-chain reach

The order pairs exclusion from civilian-agency procurements with removal from existing civilian-agency IT. Its appendix provides for immediate procurement exclusion and removal within 60 days of issuance, or an exception. That deadline is tied to issuance, not automatically restarted by publication. The stated coverage excludes national-security and secure compartmented systems. DHS presents the measure as a response to supply-chain and data-security risks; publication does not establish that every deployment suffered a breach.

CyberScoop independently reported the notice on October 19, describing the restrictions as a federal civilian-agency measure and highlighting its inclusion of affiliates and third-party implementations. Its reporting corroborates the public notice, while the order remains the controlling source for what agencies have been instructed to do. CyberScoop’s report provides contemporary reporting on the announcement.

The supplier implication is significant. An agency may buy a service under one brand while the service relies on a different company’s underlying model. Checking only the name on the invoice would not answer whether that implementation falls within the measure. That is an operational inference from the scope, rather than evidence that a particular unnamed vendor is violating the order.

Why model provenance becomes a procurement question

The Federal Acquisition Regulation describes FASCSA orders as tools for excluding specified sources or covered articles from procurement, or removing covered articles from government information systems. It also sets out an information-sharing role for contracting officers and programme offices concerning relevant supply-chain risks. This framework predates the present DeepSeek notice. The acquisition regulations provide the broader procurement context.

For a software buyer, that means a useful inventory needs to distinguish the application, its model, its hosting arrangement and its supporting services. These layers can be supplied by separate businesses. An application’s marketing description is therefore an incomplete account of what is actually running. A change in an underlying model can also change the inventory without an obvious change to the customer-facing interface.

This is particularly relevant to organisations that sell multiple configurations of one product. A locally hosted version, a cloud service and a managed integration may share branding while having different data flows and dependencies. A procurement review has to identify the particular implementation under consideration. It cannot assume that an assessment of one configuration automatically applies to every other configuration sold under the same name.

Hosted services and downloadable models raise different questions

DeepSeek’s own privacy policy says that personal data collected through its covered services is processed and stored in the People’s Republic of China. It identifies a Chinese company as the service controller and explains that its policy does not cover every downstream system developed by users of its open-platform services. That is a direct company disclosure about the policy’s scope, rather than a finding about every independently deployed model. DeepSeek’s privacy policy is the relevant primary source.

The practical distinction is between where a model originated and where a particular service processes information. Those questions overlap, but they are not interchangeable. Downloading model weights for a controlled environment does not, by itself, show that prompts go to the developer’s hosted service. Equally, a local deployment does not establish that every component, integration or update mechanism is trustworthy.

Readers should therefore avoid two sweeping conclusions: that every use of a model necessarily sends the same data abroad, or that local hosting resolves every supply-chain concern. Neither follows simply from the existence of downloadable weights. The important evidence is the architecture, configuration, permissions and observed behaviour of the specific system. Policy scope and technical risk need to be assessed separately.

DeepSeek’s continuing product development is a separate issue

The company continues to publish information about its models through its own documentation and transparency materials. Its transparency centre identifies model releases and links to supporting model cards and technical reports. Those materials describe the developer’s products; they are not a government procurement approval or an independent security certification. DeepSeek’s transparency centre provides the company’s account.

That distinction prevents a common confusion in AI coverage. A company can release a technically capable system while a public institution decides it is unsuitable for a particular environment. The institution’s decision can turn on data handling, supplier relationships or legal obligations rather than the model’s ability to solve a benchmark. A product announcement and an exclusion order answer different questions.

For the same reason, the federal notice should not be presented as a new score in a competition between national model developers. It does not measure coding accuracy, mathematical performance or inference speed. A procurement restriction is a decision about permitted use in specified systems. Evaluating whether it is justified requires attention to the stated risks and evidence, not a substitution of benchmark rankings for security analysis.

The current API documentation offers a concrete example of why inventories need version detail. It says requests using the deepseek-flash name are served by DeepSeek-V4.1-Flash-1017, while certain older model names remain accepted but route to that newer model. A familiar configuration label can therefore persist even when the model serving it has changed. The developer’s API documentation describes that routing.

This is not evidence that an agency uses that interface. It illustrates a question a buyer would need to ask a supplier: does a configured name select a fixed model version or follow a changing service? Recording that answer makes later reviews more meaningful. Otherwise, an earlier evaluation might be treated as current even after the implementation it assessed has changed. The same review principle applies across suppliers that offer evolving hosted services.

What independent capability testing can tell us

The National Institute of Standards and Technology published a CAISI evaluation of DeepSeek V4 Pro in May. It compared performance across several evaluation domains and noted differences between benchmarks highlighted by the developer and CAISI’s wider suite. The report also examined cost comparisons under stated conditions. It is an assessment of a specified model at a specified time, not a blanket judgement about every subsequent DeepSeek product. NIST’s evaluation supplies that independent context.

The methodological lesson is useful beyond this company. A benchmark comparison depends on the tasks selected, the model version, the resources allowed and how success is scored. A lower advertised token price does not automatically mean every completed task costs less. Likewise, a strong result on one task family does not establish safe handling of sensitive information. Performance, operating cost and security are separate dimensions of a deployment decision.

For public-sector buyers, that separation should make the evidence easier to organise. Capability tests can establish whether a proposed tool is useful. Security reviews can establish how it behaves within an organisation’s boundaries. Procurement checks can establish whether the acquisition is permitted. Passing one of those tests does not remove the need to satisfy the others.

Security responsibilities continue after a model choice

Joint secure-AI development guidance announced by CISA and the United Kingdom’s National Cyber Security Centre applies across the AI lifecycle, including design, development, deployment and operation. It is directed at providers using both internally hosted models and external APIs. Its emphasis on accountability and secure design is broader than any single developer or national origin. CISA’s guidance announcement explains that approach.

A separate multinational deployment guide published through the U.S. Department of Defense describes the need to protect models, data and intellectual property during deployment. It provides context for controls around access, infrastructure and ongoing operation. Those recommendations do not turn into a guarantee simply because a system uses an approved supplier. The secure-deployment guide treats security as a continuing organisational responsibility.

Replacing a model therefore creates practical questions of its own: whether the replacement can perform required tasks, whether integrations still behave correctly, whether permissions remain appropriate and whether monitoring covers the new configuration. These are implementation considerations, not a claim that agencies have completed the transition. The public notice reviewed for this report does not provide an agency-by-agency completion ledger.

What today’s notice establishes, and what it leaves open

The verified news is the public documentation of a federal civilian-agency exclusion and removal measure with an unusually important third-party dimension. Its July issuance date must travel with its October publication date in any accurate account. Its scope should also travel with the headline: this is not evidence of a general ban on every private individual using DeepSeek.

Outstanding questions include the extent of affected deployments, the handling of exceptions and the status of implementation across agencies. Those require further official reporting. Until then, the most useful response is to follow the actual order and the architecture of actual systems, rather than infer either universal compromise or universal safety from a brand name. Our earlier report on cloud independence testing examines a related distinction between a technical demonstration and the broader questions of institutional control.