The Mission Assurance Security Standard for Software (MA-S2) was published by Palantir Technologies as a candidate standard on May 17, 2026. Four control domains, each with a list of disqualifying deficiencies, specific failures that mean the standard isn't met. The document is at ma-s2.com.
If you read it carefully and walk through your own program against the four domains, the experience is uncomfortable. The standard names, with procurement-grade specificity, the things your program is most likely doing wrong because that's how the previous era's standards were written. CVSS-only severity sorting. MTTR assembled from spreadsheets. "Attack path" used as a feature-card label rather than a real graph. Suppression by email thread. None of those pass MA-S2.
This is the first AI-era security standard with teeth. It will outpace voluntary adoption.
MA-S2 is structured around four control domains. Each domain has multiple controls; each control names disqualifying deficiencies that cause automatic failure. The four domains are:
CVS — Continuous, AI-Augmented Vulnerability Scanning. Automated per-release scanning across all dependency types. EPSS and KEV enrichment alongside CVSS. AI-assisted novel-vulnerability discovery. Automatic escalation of Critical and High findings with interim mitigation. One-action recall or quarantine across the fleet for findings with known exploits.
Disqualifying: "Uniform SLAs based on CVSS score alone." Vendors using CVSS without EPSS or KEV enrichment "are not meeting this control."
APM — Attack Path Modeling and AI-Assisted Adversarial Simulation. Multi-stage attack path modeling. Adversarial AI simulation testing. Contextual triage that incorporates the path model into prioritization. Threat-intelligence integration informed by MITRE ATT&CK.
Disqualifying: "No attack path modeling. No AI adversarial simulation. No contextual triage. No threat intelligence integration."
INV — Real-Time Software Inventory and Domain Awareness. Machine-readable SBOMs with exact version pinning. Runtime reconciliation between declared and actual inventory. Environment-level visibility via API. Supply chain visibility upstream of direct dependencies. Coverage of air-gapped environments.
Disqualifying: Lacking machine-readable inventory, no runtime reconciliation, no upstream supply chain attestation.
ARO — Autonomous Remediation Orchestration. Automated patch deployment with zero-downtime capability. Fleet-wide orchestration from a single control plane. Compliance-aware change management. Formal suppression mechanisms with audit trails. MTTR and SLA compliance generated from platform telemetry.
Disqualifying: "MTTR by severity tier" generated by hand rather than from telemetry. No fleet-wide one-action recall.
Read this list with the question "would my program pass each of these today?" If the honest answer is no on two or more, you're in the majority of security programs reading the standard. That's by design. The standard is naming the gap.
Standards usually trail practice by a decade. SOC 2, FedRAMP, NIST SP 800-53 all took years to encode practitioner consensus. MA-S2 is moving ahead of the encoded consensus because the consensus hasn't formed yet, and the exposure realization window doesn't have time to wait for it.
The exposure realization window is the time between an exposure existing (CVE published, credential leaked, misconfig present, supply chain package compromised) and an adversary realizing value from it. For CVE-based exploitation, the window has compressed from weeks to days; 30% of exploited CVEs are weaponized on disclosure day. For credentials, 60% of leaked credentials are exploited within 12 hours. For exposed cloud databases, Postgres honeypots are compromised within 30 seconds of public exposure. For full-environment compromise, an LLM-based pentest agent (Excalibur, February 2026) compromised four of five hosts in a realistic enterprise Active Directory environment for $28.50 in API fees.
The Chinese state-sponsored GTG-1002 campaign disrupted by Anthropic in September 2025 ran 80-90% of attack operations autonomously against approximately 30 global targets at thousands of requests per second. The Mexican government breach between December 2025 and February 2026 saw a small criminal group use Claude Code and GPT-4.1 to exfiltrate 195 million taxpayer records via 5,317 AI-executed commands across 34 sessions. Each of those incidents was an AI walking the kill chain end-to-end at machine speed.
Verizon's DBIR 2026 confirmed the pressure with industry-wide data. For the first time in 19 years, vulnerability exploitation surpassed stolen credentials as the #1 initial access vector for breaches, jumping to 31%. Credential abuse fell to 13%, a sharp reversal. Median time-to-patch rose from 32 to 43 days, a 34% increase, while AI-paced exploitation collapsed defender-response time to hours. Patched vulnerability instances reached 63.7M in 2025, while inbound volume hit 527M, nearly 8x the 2022 baseline. Only 26% of critical KEV vulnerabilities were fully remediated in 2025, down from 38% the year before. The defender side is going backward while attacker time-to-exploit accelerates.
This is the curve standards have to react to. MA-S2 reacts by saying: if you're a critical-software vendor and your program is still optimized for the pre-AI cost model, you don't pass.
The four control domains are not best-practice recommendations. They're a structural diagnosis of where most programs fail today.
CVS codifies the end of severity-only prioritization. Every legacy vulnerability management program ranks by CVSS and works top-down. MA-S2 says: stop. Add EPSS for probability. Add KEV for confirmed exploitation. Add reachability, is the vulnerable function actually called by your first-party or transitively included code, and is it reachable from attacker-controllable surfaces? Vendors who don't do this "are not meeting this control."
APM codifies attack-path modeling as a baseline. Single-finding triage doesn't model how an adversary actually compounds findings into a kill chain. MA-S2 requires multi-stage path modeling and AI adversarial simulation. Most CSPMs without graph correlation features fail this. The graph isn't a UI flourish anymore; it's a required control.
INV codifies runtime-reconciled inventory. Build-time SBOMs are not enough; the standard requires reconciliation between declared inventory and what's actually running. Configuration drift, partial applies, console edits, and supply chain shifts all need to be visible continuously. Programs that produce SBOMs once at build time and never reconcile fail this control.
ARO codifies autonomous remediation orchestration with telemetry-driven MTTR. This is the most disruptive of the four for current operating models. Tickets, change boards, monthly maintenance windows, MTTR spreadsheets compiled quarterly, none of that passes. Fleet-wide one-action recall for findings with known exploits, executed by orchestration that doesn't depend on per-environment manual intervention. Human approval may gate execution, but the orchestration mechanism itself must be platform-native. MTTR must be computed from the platform's telemetry, not assembled by hand.
The structural pattern across all four: the standard requires that verification and remediation be code-native, telemetry-driven, and continuous. It explicitly disqualifies the configurations most programs run today.
Take the four domains and map them to the products in your current security stack:
For CVS: Your SCA tool (Snyk, Dependabot, Sonatype, Mend) catches presence. If you've added a reachability-aware SCA (Endor Labs, Snyk Reachability, Socket, Backslash, Phylum), you cover the source-code reachability requirement at the function level. None of these tools enrich CVSS with EPSS and KEV, drive SLAs from that enrichment, and execute one-action fleet recall in a single integrated platform. Each piece exists somewhere; few programs have them integrated end-to-end with operationally-coherent SLAs.
For APM: Your CSPM (Wiz, Orca, Prisma Cloud, Defender for Cloud, Lacework) likely has some form of attack-path graph. Wiz and Orca lead this; some others are catching up. The MA-S2 bar isn't just "show me a graph." It's multi-stage chain composition with MITRE ATT&CK-aligned techniques, AI adversarial simulation as a continuous testing function, and contextual triage that incorporates path output into prioritization. Most CSPM graphs surface findings; they don't drive the prioritization. They certainly don't run adversarial simulations.
For INV: Your container scanner (Trivy, Anchore, Grype, Snyk Container, Aqua) produces SBOMs at build time. Your CMDB (if you still have one) is probably stale. Your CSPM has cloud inventory, but not runtime reconciliation to what's actually loaded in process memory. Your runtime tools (Falco, Sysdig, CrowdStrike Falcon Cloud) see behavior, not declared inventory deltas. The reconciliation between "what we built" and "what's running," across air-gapped environments, with supply chain attestation upstream, is a stack-spanning workflow that doesn't sit cleanly in any one product.
For ARO: Your remediation today probably involves Jira tickets, monthly maintenance windows, change advisory boards, and an MTTR number assembled quarterly from spreadsheets. MA-S2 disqualifies that pattern explicitly. The standard requires Terraform-grade, GitOps-grade, platform-native orchestration with telemetry-driven SLA reporting. The category of tools that does this end-to-end doesn't have a settled name yet.
If you read the four maps honestly, what you'll likely find is: some MA-S2 requirements are partially covered by tools you already have; none are covered end-to-end; and the integration work to assemble them into a single passing program is the gap. That integration work is what the standard is, at its core, requiring.
MA-S2 is detailed on what the controls require. It's less direct on the category of product that pulls them all together. The standard is layered (CVS, APM, INV, ARO) but the programs that pass it operationally are not assembled from four separate products. They're assembled from a verification-and-remediation layer that consumes scanner output, walks the chain across the architectural layers, verifies which findings actually fire in this environment, and executes code-form remediation across the fleet.
There's also a quieter problem MA-S2 implies but doesn't name: latent state. The standard requires reachability "at source code and dependency level (is the function actually called?) and runtime level (is it reachable from attacker-controllable surfaces?)." Observation-based tools, runtime monitors, ADR products, EDR, see what's actually been exercised. They don't see what could be exercised but hasn't been. Latent code, latent config, paths that exist but no traffic has hit yet, these are structurally invisible to observation. They're also exactly the surface AI-driven offense enumerates first, because AI offense has the compute and patience that human attackers don't.
A program that verifies reachability with observation alone passes MA-S2 nominally but fails the underlying intent the moment AI-paced offense walks a latent path nobody had triggered. Closing the latent gap requires deterministic verification, probes that check whether the conditions for exploitation are met regardless of whether anything has exercised the path yet. That requirement is implicit in MA-S2's framing but worth making explicit, because the programs that pass on paper and still get breached will fail on this exact distinction.
The standard is going to drive evaluations whether or not your program is ready. Ask:
If two or three of those are uncomfortable, the standard just named your deficiencies.
MA-S2 is the first AI-era security standard with disqualifying deficiencies. It will get adopted by procurement teams faster than voluntary modernization can catch up, because the realization-window pressure is real, the incidents are public, and the standard has a credible enterprise sponsor positioning it as required for critical software providers.
For practitioners, the standard is a gift: it ends the ambiguity about whether CVSS-only severity sorting, ticket-based MTTR, and scanner stacks without integrated graph correlation are acceptable in the post-AI era. They're not. The standard says so explicitly.
For programs, the work is the integration layer that makes the four domains pass operationally, and that integration layer is what the next category of security platform builds. Standards-driven adoption pressure and AI realization-window pressure compound. The window to build the verification and remediation layer that paces both is closing. Either build it, or document the risk you can't manage.
Pretending coverage is the failure mode the standard exists to flag.