Executive Order 14409 puts frontier AI cyber capability at the centre of US federal security policy, yet the parts that matter most to developers and operators were designed in confidence and have not been published. President Trump signed "Promoting Advanced Artificial Intelligence Innovation and Security" on 2 June 2026, and it appeared in the Federal Register on 5 June 2026 at 91 FR 34565. It tasks agencies to harden federal systems with AI, creates an AI cybersecurity clearinghouse, sets up a classified process for designating "covered frontier models", invites developers into a voluntary pre-release access framework, and directs the Attorney General to prioritise prosecutions of AI-enabled intrusions. This guide reads the order section by section, separates what is binding from what is voluntary, records what has happened since (status as at 11 November 2026), and sets out what security, GRC, AI platform and procurement teams should do about it. For the wider stack of OMB memos and earlier AI orders, see the US Federal AI Policy Guide.
Source note: obligations and deadlines come from the order text on whitehouse.gov and the Federal Register. Implementation status comes from the Congressional Research Service and named secondary sources, which are identified where used. Executive orders can be amended or revoked at any time: check the official text before relying on this page. Confirm against the official text before relying on it. Compliance steps, decision guidance and checklists on this page are NHI Mgmt Group recommendations, not requirements of the text.
Key takeaways
- It binds agencies, not companies. Every mandatory tasking falls on federal officials; developers and critical infrastructure operators take part voluntarily, and the order creates no enforceable rights.
- "Covered frontier model" has no public definition. The threshold is set by a classified benchmarking process and the Director of NSA makes the designation, so a vendor cannot self-assess from published criteria.
- The pre-release window is up to 30 days. Developers who opt in give the government access before release to other trusted partners; reporting says the leaked draft proposed 90 days.
- No licensing regime. Section 3(c) states the order does not authorise mandatory licensing, preclearance or permitting for developing or releasing AI models.
- The downstream effects are real. CISA's BOD 26-04 on risk-based patching and the Gold Eagle clearinghouse followed within weeks, and prosecutors are told to prioritise AI-enabled unauthorised access, including by AI agents.
Status and timeline
| Date | Event | Source |
|---|---|---|
| 2 June 2026 | EO 14409 signed, after a postponed signing and a leaked draft | Order text; Freshfields |
| 5 June 2026 | Published at 91 FR 34565 (FR Doc 2026-11415); NSPM-11 on AI for national security issued the same day | Federal Register; CRS IF13268 |
| 10 June 2026 | CISA issues BOD 26-04, Prioritizing Security Updates Based on Risk, which press reporting links to the order's priorities | CyberScoop |
| 2 July 2026 | 30-day taskings due: CNSS, Department of War, CISA directives, clearinghouse formation, OMB grant review | CRS IF13268 |
| July 2026 | Gold Eagle announced as the AI cybersecurity clearinghouse, led by CISA, Treasury and the Department of War | SecurityWeek |
| 1 August 2026 | 60-day taskings due: classified benchmarking, voluntary framework, OPM hiring pathways | CRS IF13268 |
| August 2026 | Framework reported as finalised but not published | Cloud Security Alliance research note |
The order revokes nothing. It sits alongside EO 14179, EO 14365 and the OMB AI memos rather than replacing them.
What the order requires, section by section
| Section | Who acts | What they must do | Deadline |
|---|---|---|---|
| 2(a) | Committee on National Security Systems | Prioritise cyber defence of National Security Systems (as defined in 44 U.S.C. 3552(b)(6)(A)) | 30 days |
| 2(b) | Secretary of War | Prioritise cyber defence of Department of War information systems | 30 days |
| 2(c) | Secretary of Homeland Security through CISA, with OMB, the National Security Affairs Assistant and the National Cyber Director | Issue Binding Operational Directives and guidance to prioritise civilian federal cyber defence, expand AI-enabled defensive tools, and widen access to tools, including covered frontier models where appropriate, for agencies, state and local authorities and critical infrastructure such as rural hospitals, community banks and local utilities | 30 days |
| 2(d) | Treasury, with the National Cyber Director, NSA and CISA | Form a voluntary AI cybersecurity clearinghouse with industry that coordinates and deconflicts vulnerability scanning, validates findings and prioritises remediation and patch distribution | 30 days |
| 2(e) | OMB, with the National Cyber Director and CISA | Determine whether federal grant programmes can fund advanced AI vulnerability detection | 30 days |
| 2(f) | Office of Personnel Management | Expand US Tech Force cybersecurity specialist hiring and placement pathways | 60 days |
| 3(a) | Treasury, Department of War through NSA, DHS through CISA, with the National Cyber Director, APST and Commerce through NIST | Develop and maintain a classified benchmarking process for advanced cyber capabilities and set the covered frontier model threshold; the NSA Director makes the designation | 60 days |
| 3(b) | Same group | Design a voluntary framework with developers (see below) | 60 days |
| 3(c) | None | Limit: no mandatory licensing, preclearance or permitting | Not applicable |
| 4 | Attorney General | Prioritise enforcing 18 U.S.C. 1028, 1030 and 1343 against anyone who uses AI to access or damage a computer without authorisation, including AI agents used to access data unlawfully | Ongoing |
| 5 | All | Standard general provisions: subject to law and appropriations, no enforceable rights | Not applicable |
The order has no definitions section. The Center for AI Standards and Innovation is not named; NIST appears only as a consulting party under Section 3(a).
Covered frontier models and the pre-release access framework
Section 3 is the part most developers ask about. Under Section 3(b) the voluntary framework lets a developer do three things:
- Ask for a determination: engage the government to find out whether a model under development meets the covered frontier model designation.
- Give early access: provide the government with access to a covered frontier model "for a period of up to 30 days before they plan to release such models to other trusted partners", subject to confidentiality, cybersecurity, insider risk and intellectual property protections.
- Choose early-access partners: work with the government to select trusted partners, such as critical infrastructure operators, that get early access to support secure innovation and defence.
What has not been published
The Congressional Research Service notes that the order does not define "covered frontier model" and that funding and technical roles are unclear. The Cloud Security Alliance reported in August 2026 that the framework had been finalised by its deadline but not released, and listed what remains unpublished: the framework text, the benchmark and threshold, evaluator identities, the number and outcome of reviews, any appeal route, eligibility criteria for organisations receiving access, and what happens if a 30-day window lapses without a decision. The same note reports that open-weight models are outside the framework; treat that as reported, not confirmed by an official text.
Practical reading: a model's status under EO 14409 is invisible to customers. If you depend on a frontier model, its release could be delayed or shaped by a confidential review, and you will not see the reasons.
How it differs from the 2023 approach
| Feature | EO 14110 (2023, rescinded) | EO 14409 (2026) |
|---|---|---|
| Legal basis for developer duties | Defense Production Act reporting for dual-use foundation models | None: participation is voluntary |
| Trigger | Published compute thresholds | Classified cyber capability benchmark set by an NSA-led process |
| What developers share | Training activity, weight security, red-team results | Pre-release model access for up to 30 days, on opt-in |
| Scope of concern | Broad: safety, bias, biology, cyber and more | Narrow: advanced cyber capability and national security |
| Licensing | None | Expressly ruled out by Section 3(c) |
The clearinghouse and federal vulnerability management
- Gold Eagle: SecurityWeek reported in July 2026 that the White House launched Gold Eagle with CISA, Treasury and the Department of War as the vehicle for the Section 2(d) clearinghouse. It pairs open source maintainers with critical infrastructure operators in a shared reporting and remediation pipeline and aims to cut duplicate scanning. Participation is voluntary. See the Gold Eagle AI Vulnerability Clearinghouse Guide.
- BOD 26-04: CyberScoop reported that CISA issued BOD 26-04 on 10 June 2026. A vulnerability that affects a publicly exposed asset, allows fully automated exploitation, gives control of the system and has evidence of active exploitation must be remediated within 3 days, with forensic triage for compromise. Agencies have 60 days to update processes and 180 days to meet the new timelines. BODs bind federal civilian agencies only, though CISA encourages others to adopt them. Read the directive on cisa.gov before acting; this summary relies on press coverage.
- Funding: CRS notes the order relies on existing appropriations and that Treasury did not specifically request FY2027 funding for the clearinghouse. Expect capacity to vary.
For non-federal teams, the shift to machine-speed vulnerability discovery is the operational signal. If AI models find and validate flaws faster, the time between disclosure and exploitation shrinks, and patch windows built around 15 or 30 days stop being defensible for internet-facing assets. See the CISA KEV Catalogue Guide and the CIS Control 7 Continuous Vulnerability Management Guide.
Criminal enforcement and where identity fits
Section 4 creates no new offence. It tells the Attorney General to prioritise three existing statutes: 18 U.S.C. 1028 (fraud involving identification documents and means of identification), 18 U.S.C. 1030 (the Computer Fraud and Abuse Act) and 18 U.S.C. 1343 (wire fraud). The order names AI agents used to access data unlawfully. Two consequences for security teams:
- Attribution depends on agent identity: to show an agent acted within authorisation, or to support a referral when someone else's agent did not, you need to know which agent ran, under which credential, on whose behalf. Unattributed shared API keys make that impossible. See the US Computer Fraud and Abuse Act Guide.
- Leaked keys turn agents into intruders: in the OpenAI agents and US government websites case, agents found other people's Census Data API keys in public repositories and used them. Secret scanning, scoped keys and rotation are the controls that keep your credentials out of that story. See the API Key Management Guide.
Who is affected and how
| Organisation | Direct obligation | Practical exposure | First action |
|---|---|---|---|
| Federal civilian agency | Yes, through CISA directives and OMB tasking | BOD 26-04 timelines, AI defensive tooling programmes | Map BOD 26-04 criteria to asset inventory and exposure data |
| Frontier model developer | No | Possible designation and invitation to the framework; confidential review before release | Decide with counsel whether to engage; plan release schedules for a 30-day window |
| Federal contractor or cloud provider | Only through contract terms | Flow-down clauses citing covered model status or directives | Review new solicitations and modifications for references to the order |
| Critical infrastructure operator | No | Access to AI tools, clearinghouse participation, faster disclosures | Decide on Gold Eagle participation; shorten patch windows for exposed assets |
| Enterprise AI customer | No | Model availability may change without public reasons | Add EO 14409 questions to AI vendor due diligence |
What to do now: an implementation sequence
- Classify your position. Agency, contractor, developer, operator or customer: the actions above differ completely. Record the decision and the date in your regulatory register (CSF 2.0 GV.OC-03).
- Inventory AI dependencies. List every frontier model, provider and API your products and internal agents rely on, with the owner and the credential each uses.
- Update AI vendor due diligence. Ask whether the vendor has engaged with the EO 14409 framework, whether any hold or restriction affects products you use, and how they will notify you of material delays. See the AI Vendor Security Questionnaire Template.
- Add a continuity scenario. Test what happens if a model you depend on is withdrawn, delayed or altered without explanation: fallback model, degraded mode, contract exit.
- Pilot a faster patch tier. Use the four BOD 26-04 criteria as a triage rule for exposed assets; run it in report-only mode for a month, compare against current SLAs, then enforce. Roll back to the previous SLA set if the change queue becomes unmanageable, and record why.
- Tighten agent credentials. Give every AI agent its own identity and scoped credential, log every call, and turn on secret scanning for public and private repositories.
- Review quarterly. The framework may be published, amended or overtaken by legislation; see the US Federal AI Bills Tracker.
Decision guidance
- Developers: engage or not. Engaging gives early clarity on designation and a say in trusted partner selection; it costs schedule time, confidential disclosure and dependence on unpublished rules. Larger labs with government customers have more reason to engage; a small developer far from the threshold may simply monitor.
- Operators: join the clearinghouse or not. Joining brings prioritised remediation guidance and earlier signals; it needs a contact point, a process to act on findings, and legal review of information sharing terms. Small operators without a vulnerability team should first fix their intake process.
- Customers: treat status as unknown. Do not read silence about framework status as compliance or exemption; record it as a supply chain unknown in your risk register.
Detection and measurement
- Coverage: percentage of production AI dependencies with a completed vendor assessment that includes EO 14409 questions (target 100 percent for critical services).
- Exposure speed: median hours to remediate exposed, actively exploited vulnerabilities, against a 72-hour tier.
- Continuity: date of the last tested model-withdrawal scenario and time to switch to the fallback.
- Agent attribution: percentage of AI agent calls to internal or external APIs attributable to a named agent identity, not a shared key.
- Secret exposure: mean time to revoke an AI provider or API key found in a repository.
Common failure patterns
- Reading "voluntary" as "irrelevant": directives under Section 2(c) bind agencies, and agencies pass requirements to suppliers through contracts.
- Assuming a public threshold exists: teams look for a compute or capability number to self-assess against; there is none in public.
- Treating the order as a safety regime: it addresses cyber capability and national security, not bias, privacy or general model safety; other obligations still apply.
- Leaving patch SLAs unchanged: keeping 30-day windows for internet-facing systems while AI-assisted discovery accelerates exploitation.
- Shared credentials for agents: agents running on one team key cannot be attributed, which undermines both incident response and any criminal referral.
Framework mapping
| Order element | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 |
|---|---|---|---|
| Tracking the order and directives | GV.OC-03 | PM-9 risk management strategy | Not directly mapped |
| Clearinghouse findings and disclosures | ID.RA-01, ID.RA-08 | RA-5, SI-2 | Control 7 |
| AI vendor dependency and status unknowns | GV.SC-07 | SR-3, SR-6 | Control 15 |
| Developer pre-release evaluation | ID.RA-01 | SA-11 | Control 16 |
| Ongoing monitoring of agent activity | DE.CM-09 | CA-7, AU-6 | Control 8 |
Practitioner checklist
- Record your organisation's position under EO 14409 and the date checked.
- Inventory frontier models and AI APIs in use, with owners and credentials.
- Add EO 14409 framework questions to AI vendor assessments and renewals.
- Scan new federal solicitations and contract changes for references to the order or covered models.
- Run a tabletop for a dependent model being withdrawn or delayed.
- Adopt a 72-hour tier for exposed, actively exploited vulnerabilities, piloted before enforcement.
- Decide on Gold Eagle participation if you operate critical infrastructure.
- Give each AI agent its own scoped identity and enable secret scanning.
- Review the order's status and any published framework each quarter.
Standards and references
- The White House: Promoting Advanced Artificial Intelligence Innovation and Security
- Federal Register (govinfo): Executive Order 14409, 91 FR 34565
- The White House: Fact Sheet on Promoting Advanced AI Innovation and Security
- Congressional Research Service: Executive Order 14409 Explained (IF13268)
- Cloud Security Alliance: EO 14409's Classified Frontier AI Framework
- Freshfields: Trump Executive Order on AI, Voluntary Framework and Cybersecurity Focus
- SecurityWeek: White House Launches Gold Eagle Vulnerability Coordination Initiative
- CyberScoop: CISA Directive BOD 26-04 on Prioritising Vulnerability Patching
Related NHI Mgmt Group resources: US Federal AI Policy Guide · US Federal Cybersecurity Executive Orders Guide · Frontier AI Model Risk Frameworks Guide · Gold Eagle AI Vulnerability Clearinghouse Guide. This guide summarises Executive Order 14409 and is not legal advice.