You've spent years mapping detections, playbooks, and tabletop scenarios to MITRE ATT&CK techniques and Common Vulnerabilities and Exposures (CVE) identifiers. Then, in April 2025, MITRE warned that Federal funding for its CVE program would expire on April 16, and only a last‑minute 11‑month extension from CISA kept it alive.
At the same time, CISA is shrinking due to budget cuts, layoffs, and furloughs.
What exactly has changed with MITRE and CISA funding?
The short take:
MITRE's CVE program narrowly avoided a shutdown when its DHS contract nearly expired in April 2025 and was extended for only 11 months, while ATT&CK itself remains actively funded and continues to evolve with the v18 release.
Meanwhile, CISA faces significant proposed budget and staff cuts, along with a six-week shutdown that furloughed most of its workforce, reducing the public capacity for ATT&CK-aligned guidance and services.
Let's start with the CVE scare. In early April 2025, MITRE told the CVE board that the current Department of Homeland Security (DHS) contract allowing MITRE to run and update the CVE and Common Weakness Enumeration (CWE) programs was set to expire on April 16, 2025. The DHS had not yet renewed the long-standing contract, and public reports described the CVE program as "slated for an abrupt shutdown" on that date if no action was taken.
That shutdown did not occur.
Following industry concern, CISA exercised an option period on its contract with MITRE the night before it expired, granting an 11‑month extension and preventing a lapse in CVE services until roughly March 2026. The program remains operational, but its future is contingent upon short Federal budget cycles and shifting political priorities.
ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is different. As of now, there are no public reports that MITRE ATT&CK's funding has been cut; the recent v18 release actually shows active development, even as CVE faces specific contract issues. MITRE released ATT&CK v18 on October 28, 2025, updating Enterprise, Mobile, and Industrial Control Systems (ICS) matrices and delivering one of the most significant defensive overhauls in the framework's history.
Instead of simple "Detections" and "Data Sources," techniques now reference more advanced detection strategies, analytics, and revised data. In other words, while CVE funding faces an uncertain future, ATT&CK continues to evolve.
The broader ecosystem around ATT&CK is less robust. CISA, one of ATT&CK's leading champions and a major funder of public cyber initiatives, is under ongoing stress. The current administration's FY2026 budget proposal would reduce about 1,000 funded positions at CISA, roughly a third of its workforce, along with several hundred million dollars in cuts to its operating budget, especially impacting risk management and stakeholder engagement work.
Separate reports in 2025 indicated that at least 130 CISA positions were eliminated early in the year, with additional layoffs and reassignments occurring later in the year.
Overlay this with a six-week Federal shutdown from October 1 to November 12, 2025. During that funding lapse, CISA retained only about one-third of its staff (roughly 889 out of 2,540 employees) under DHS's contingency plan, with the rest furloughed. A Washington Post analysis in late November described CISA as having already experienced a one-third staff reduction overall and carrying a vacancy rate of nearly 40% in key mission areas.
That combination of structural cuts and episodic shutdowns means fewer public resources, fewer outreach programs, and less capacity for the ATT&CK-aligned guidance you relied on over the past decade.
How does this funding turbulence really touch MITRE ATT&CK?
The short take:
While funding instability hasn't directly affected ATT&CK, which remains healthy and is updating with v18, the same structural funding risks that nearly disrupted CVE remain. Additionally, CISA's budget cuts and overload are undermining the ecosystem that supports, funds, and implements ATT&CK for users.
At first glance, ATT&CK appears isolated. However, it's still healthy. V18 landed on schedule, and the public matrices and STIX bundles (JSON-encoded containers that package ATT&CK objects for tools to consume programmatically) remain accessible, with no announcement that the framework is being frozen or discontinued.
Underneath, the same structural risks that affect CVE also apply. ATT&CK is a curated knowledge base maintained by a federally funded R&D center. It requires full‑time analysts, engineering support, and ongoing community involvement to keep campaign mappings current and ensure quality across multiple areas. The April 2025 CVE scare demonstrated how quickly a single contract decision can jeopardize such work. Even if ATT&CK is funded through different mechanisms, it operates within the same political and budgetary framework.
CISA's condition also matters. Even if MITRE continues to update ATT&CK, a smaller and more overwhelmed CISA has less capacity to promote threat-informed defense, incorporate ATT&CK into guidance, or fund related efforts such as sector-specific mappings and training.
So, the direct maintenance of ATT&CK isn't in crisis today, but the ecosystem that helps you adopt and operationalize it is under real strain. That's the nuance you need to consider in your planning discussions.
Is ATT&CK still a viable backbone if updates slow down?
The short take:
Yes. ATT&CK remains a reliable foundation, even if updates are slow, because its stable technique vocabulary keeps your current mappings consistent. However, you'll increasingly need to add your own extensions, mappings, and versioning as attacker behavior, especially in cloud and AI, outpaces the framework's development.
From a purely structural perspective, ATT&CK remains a rock-solid foundation.
The main value of the framework is its shared, stable vocabulary for adversary behavior and a consistent way to map detections, procedures, and controls. Even if the update pace slows down, "T1059" remains as "Command and Scripting Interpreter," and all your existing detections, test cases, and tabletop scenarios referencing it stay consistent.
The risk isn't that your current ATT&CK‑mapped universe suddenly fails. The real risk is that the model fails to keep up with attacker behaviors at the required speed. AI-assisted operators are already finding new ways to combine techniques, automate discovery, and adapt phishing, social engineering, and intrusion workflows more quickly than human analysts can produce case studies. A framework that evolves too slowly will tend to fall behind those evolving patterns by months or years.
If ATT&CK updates become less frequent or narrower in scope, emerging techniques, especially around cloud control planes, SaaS abuse, and AI/LLM exploitation, may be forced into existing slots instead of receiving dedicated techniques. Your incident write-ups may rely on vague or overloaded techniques, and threat intel products and research might drift away from ATT&CK mapping if it no longer provides convenient labels for new behaviors.
Even in that world, ATT&CK remains a valuable framework. It just needs more customization on your part, like adding internal extensions for new behaviors, creating mapping tables across different taxonomies, and implementing clearer versioning so you always know which "snapshot" of ATT&CK your assessments and coverage reports are based on.
What happens to tools that lean on ATT&CK mappings?
The short take:
Tools that rely on ATT&CK use it as a shared behavioral layer for detections, playbooks, intelligence, and simulations. If ATT&CK's development slows, you won't see tools "break," but coverage metrics and recommendations may become out of sync with actual attacker behavior.
Vendors might create incompatible extensions, and your team will spend more time reconciling different ATT&CK dialects and questioning headline "coverage" claims.
Your tooling does more than decorate dashboards with ATT&CK. SIEM, EDR, and XDR platforms often use ATT&CK techniques as a normalized layer for rules from different products. A detection for PowerShell abuse, another for unusual Windows Management Instrumentation activity, and a third for suspicious cloud automation may all be linked to the same lateral movement or execution techniques. This allows your analysts to focus on behavior rather than vendor-specific rule names.
Security Orchestration, Automation, and Response (SOAR) platforms usually tag playbooks with ATT&CK techniques and tactics. This allows you to route incidents and coordinate responses based on "credential access plus lateral movement" instead of "use case ID 4387." Threat intelligence platforms enhance campaigns and indicators with ATT&CK IDs, enabling you to group activity, compare it with past incidents, and prioritize based on familiar behaviors.
Exposure management, Breach & Attack Simulation (BAS), and Continuous Threat Exposure Management (CTEM) tools simulate attack paths and evaluate control effectiveness using the ATT&CK framework. Identity security platforms such as Delinea leverage ATT&CK data to improve security measures against identity-based threats and privilege escalation risks.
If ATT&CK's evolution slowed, the first thing you'd notice is not a crash but a drift. Coverage heatmaps would highlight techniques that are well understood and already fairly well defended, while newer attack patterns might be invisible at the technique layer and only visible as vendor-specific rule names.
Analytics recommendations that heavily rely on ATT&CK's defensive guidance would become less aligned with the actual threat landscape. And because vendors still need to describe new behaviors, each one would be tempted to introduce proprietary technique IDs or "extended ATT&CK" schemas that do not align cleanly with one another.
For you, that drift appears more as glue work. You would need to reconcile different vendor dialects in your own threat catalog, maintain cross‑maps, and be more skeptical of any dashboard that claims "90% ATT&CK coverage" without explicitly stating which ATT&CK version and extensions the claim actually relates to.
How could ATT&CK be complemented or replaced, and at what cost?
The short take:
ATT&CK is unlikely to be entirely replaced because your tools and processes are closely tied to its IDs. Therefore, the practical approach is to supplement it with additional models and extensions, accepting the risk of fragmentation and establishing deliberate governance on how you and your vendors extend and use those taxonomies.
There is no empty space waiting for "the next ATT&CK" to emerge. You already operate within an ecosystem of overlapping models. Sigma provides a community-driven format for detection logic that often includes ATT&CK tags but is not reliant on them.
Many vendors maintain internal catalogs of tactics, techniques, and procedures (TTPs) that go beyond ATT&CK for specific areas such as cloud IAM, SaaS configuration, or OT networks. Sector communities (like a group of banks or a cluster of energy utilities) and Information Sharing and Analysis Centers (ISACs) sometimes publish their own threat taxonomies or reference models.
Industry discussions about alternatives typically focus on practical realities; replacing ATT&CK altogether would be extremely costly. Your detections, purple-team content, training curricula, reporting templates, and many of your products' data models are tied to ATT&CK IDs. Removing that in favor of something entirely different could take years and cause new interoperability issues.
The more realistic approach is "ATT&CK plus something." Vendors will extend ATT&CK with more detailed internal hierarchies, particularly in rapidly evolving areas such as AI/LLM threats, cloud-native attack routes, and application-layer abuse. Community projects might create overlays (additional technique layers or tags) that sit on top of ATT&CK's core structures. Your team may already be doing this for behaviors relevant to your environment, but they may not yet have clear categorizations in ATT&CK.
The risk is fragmentation. If each vendor and large defender extends ATT&CK differently, you end up where you were a decade ago: ten different taxonomies describing similar behaviors in incompatible ways. That undermines the primary reason you initially adopted ATT&CK—a common language.
The only way around that is deliberate governance, meaning treating ATT&CK and related TTP taxonomies as architecture rather than just documentation.
How can you hedge against a frozen or fragmented TTP model?
The short take:
You can hedge against a frozen or fragmented TTP model by treating ATT&CK as a versioned dependency, building your own internal TTP catalog that extends it, mirroring multiple external feeds like CVE and KEV into your own stores, and actively engaging vendors on their ATT&CK usage and mappings so everything aligns with a common internal reference.
The first mindset shift is to treat ATT&CK like a software dependency. You wouldn't run a critical service with whatever build happens to be "latest" without tracking its version; you shouldn't treat ATT&CK that way either. Determine which ATT&CK version your program is currently aligned with and document that in your detection-engineering runbooks, tabletop templates, and reporting methods.
Next, develop an internal TTP catalog that leverages ATT&CK but is not restricted to it. Start by identifying the behaviors most commonly seen in your incidents and realistic attack scenarios, then assign your own internal IDs where ATT&CK is too broad or absent. For each internal technique, document relevant ATT&CK mappings, typical procedures, key log sources, and existing detection or prevention measures.
Over time, this will serve as your authoritative reference for threat-informed defense, with ATT&CK serving as a primary guide rather than the sole source of reference.
Finally, you should intentionally diversify your external inputs. The CVE contract incident is a clear example. It's a single contract decision that nearly disrupted a global identifier system on which your scanners, ticketing systems, and asset inventories likely rely. Continue consuming ATT&CK, CVE, Known Exploited Vulnerabilities (KEV), and CISA advisories, but assume any of them might be affected by politics or budget constraints in a given year. Mirror the most relevant feeds into your own data stores and normalize them there.
What should you do next to minimize your exposure to risks?
The short take:
Lock in your chosen version of the ATT&CK framework, document and expand your own TTP catalog and mappings, mirror key public feeds like CVE and KEV into your environment, and assign a small cross-functional team to oversee these taxonomies so your program remains stable even if public funding, updates, or guidance fluctuate.
There are several tangible, concrete steps you can take shortly to minimize your exposure to funding and governance risks related to ATT&CK, CVE, and CISA-hosted services.
- Snapshot your current ATT&CK dependency. Export the STIX or JSON bundles and store them in an internal repository along with your detection content and threat models so you aren't dependent on the live website for reference.
- Document your ATT&CK mappings in a centralized repo. Develop or update a core catalog that connects ATT&CK techniques to key detections, SOAR playbooks, common incident types, purple‑team scenarios, and control-validation tests. Treat it as a living artifact under change control, not just a spreadsheet stored on a single engineer's laptop.
- Expand your own TTP layer as needed. When you encounter a behavior that doesn't neatly fit into ATT&CK, particularly in areas such as AI/LLM misuse, SaaS and cloud identity abuse, or specialized OT protocols, add an internal technique entry and tag it with the closest relevant ATT&CK techniques. Don't wait for MITRE to approve every edge case before acting.
- Treat public feeds as multiple inputs, not single points of failure. Continue using CVE, CISA KEV, and other government resources, but mirror the data you rely on and identify alternative sources (ISAC feeds, commercial intel, open-source projects) if shutdowns or cuts impair those services.
- Make taxonomy governance a permanent responsibility. Form a small, cross-functional team (e.g., threat intelligence, detection engineering, red or purple team, and GRC) to manage your internal TTP catalog, review new ATT&CK updates, approve extensions, and ensure vendor mappings remain aligned.
Treating ATT&CK, CVE, and CISA's public outputs as versioned, fallible dependencies rather than permanent background tools reduces your exposure to political and budget shocks. ATT&CK v18 shows MITRE continues to advance the framework, even as CVE's contract issues and CISA's workforce reductions reveal real vulnerabilities in the public cyber infrastructure you rely on.
Your job is not to abandon ATT&CK, but to integrate it with enough local structure and governance so that your defense program remains coherent if updates slow down, funding decreases, or public guidance becomes less clear.