ARC-AMPE Flaw Remediation and Supply Chain Evidence for Vendors

CMS replaced MARS-E with ARC-AMPE (Acceptable Risk Controls for ACA, Medicaid, and Partner Entities), Version 1.0, released 4 March 2025 with a compliance date of 4 March 2026. For vendors, three things changed: the baseline moved to NIST SP 800-53 Rev. 5, remediation now runs on fixed clocks (critical in 15 days, high in 30), and a supply chain risk management family now applies.

The entity that connects to the CMS Federal Data Services Hub, whether a state Medicaid agency, a state exchange or a partner entity, answers to CMS. It passes those duties to you through its contract and through the rows of its System Security and Privacy Plan that your product touches. This post covers what the ARC-AMPE documents say about flaw remediation, scanning, inventory and the supply chain, what changed from MARS-E 2.2, and how to produce the evidence from your own pipeline without consumer data reaching your tooling.

Nothing here suggests that CMS has reviewed, approved or authorized Safeguard. CMS authorizes connections to the Hub for the entities that run them. It does not certify tools.

Key takeaways

• Version and dates, from CMS. The CMS Regulations and Guidance page lists ARC-AMPE Version 1.0 with a release date of 4 March 2025 and a compliance date of 4 March 2026. The Volume I PDF it links is revision 1.02 (10 April 2025), and the ACA Administering Entity Volume II workbook is also at 1.02.
• Who must comply. ACA Administering Entities (exchanges, state Medicaid agencies, state CHIP agencies and state agencies running a Basic Health Program) and select Partner Entities must comply with Volume II. Vendors are bound through contracts that 45 CFR 155.260(b) requires.
• Scanning moved from every 72 hours to every 30 days, plus on new vulnerabilities. MARS-E 2.2 asked for scans at least every 72 hours. ARC-AMPE RA-5 asks for scans every 30 calendar days and whenever new vulnerabilities that could affect the system are reported.
• Fixed remediation clocks. ARC-AMPE sets critical at 15 calendar days, high at 30, moderate at 90 and low at one year, and SI-2 adds that security-relevant updates go in within 30 days of their release.
• A supply chain family arrives. The AE baseline includes SR-1, SR-2, SR-2(1), SR-3, SR-8 and SR-12. SR-4 (provenance) and SR-11 are not in the AE mandatory baseline, though SR-3 invites entities to add more SR controls.
• ARC-AMPE never says SBOM or KEV. Neither term appears in Volume I or the AE Volume II workbook. An SBOM is still the practical way to answer CM-8 for software, and KEV is still the best signal for ordering work inside the 15 and 30 day windows.
• Evidence goes to CMS on a schedule. Administering Entities deliver vulnerability scans and an updated POA&M to CMS quarterly, on 31 January, 30 April, 31 July and 31 October, and CA-7 asks for monthly status reporting.
• Safeguard capabilities covered, with maturity labels: SBOM generation and analysis (GA); software composition analysis and vulnerability management with EPSS and KEV (GA); reachability analysis (GA); policies and gates (GA); the compliance and GRC suite with its NIST SP 800-53 framework page (GA); Portal, the SBOM publish and share product, with sharing and audit trails (GA); bulk export (GA); CLI (GA); MCP server (GA); on-prem and air-gapped deployment and Zero AI mode (GA); autonomous remediation (GA, ships switched off with every category set to Manual); SAST and DAST (GA, not relied on here); fork and patch (GA); desktop app. No consumer PII enters this flow.

Scope and a caution

Control text below comes from the ACA Administering Entity (AE) Volume II workbook, version 1.02. Other entity types, such as enhanced direct enrollment entities, use their own overlays and may differ.

This is not legal advice. The entity decides how it implements ARC-AMPE, CMS decides whether to grant or keep its connection to the Hub, and your contract decides what you owe. State law and other federal rules (Medicaid program rules, IRS Publication 1075 for federal tax information, HIPAA) can add more.

What is ARC-AMPE, who must implement it, and by when

The documents and their versions

ARC-AMPE is the CMS framework for securing the systems that run health coverage eligibility and enrollment. Volume I is guidance: who the users are, how authorization works, what artifacts go to CMS and how continuous monitoring fits. Volume II is the control baseline itself, delivered as an Excel System Security and Privacy Plan (SSPP) that the entity fills in row by row.

The CMS Regulations and Guidance page, as captured in October 2026, lists:

Inside the files, Volume I's record of changes shows 1.0 on 4 March 2025, 1.01 on 10 March 2025 (references updated, "No changes to the controls") and 1.02 on 10 April 2025 (accessibility). The AE workbook's change log runs the same way: approved public release, then minor updates, then a 1.02 revision that added owner columns and status fields.

Some industry summaries describe later minor revisions of the AE baseline, but the CMS page we read still linked the 1.02 workbook. Ask the entity which revision its SSPP uses before you write against it.

Who must comply

Volume I defines the users. An ACA Administering Entity is an exchange, federal or state, a state Medicaid agency, a state CHIP agency, or a state agency administering a Basic Health Program. A Partner Entity is any other entity with authority to create, collect, use or disclose exchange consumer PII, by regulation or by agreement with CMS. Partner Entities include non-exchange entities, direct enrollment and enhanced direct enrollment entities, and service providers such as income verification or dispute resolution vendors.

Volume I says Administering Entities and select Partner Entities must comply with Volume II and complete the accompanying artifacts. Everyone else may use Volume II as an informative reference. The systems in scope are those with, or applying for, an authorized connection to the Hub, or with access to PII from the exchange repositories.

Volume I is also explicit about what ARC-AMPE replaced: it "supersedes and replaces MARS-E and the NEE GRC Framework effective upon publication." The compliance date of 4 March 2026 is when the controls had to be in place.

Where the vendor comes in

You may never touch the Hub yourself, but you sit inside the boundary if your software runs in the entity's eligibility system or your team builds and maintains it. Three texts pull you in:

1. 45 CFR 155.260(b)(2). Before any person or entity becomes a non-exchange entity, the exchange must sign a contract that binds it to the privacy and security standards, requires it to monitor, periodically assess and update its security controls, requires it to report material changes, and requires it to bind any downstream entities to the same obligations. That last clause is how a subcontractor ends up with the same duties as the prime.
2. ARC-AMPE SA-4 (Acquisition Process). Its supplemental guidance says each contract and statement of work that involves development or access to systems with PII must require adherence to the entity's policies consistent with 45 CFR 155.260(b). SA-4 item h asks for the "allocation of responsibility" for security, privacy and supply chain risk management.
3. ARC-AMPE SA-9 (External System Services). It requires providers of external system services to comply with the organization's requirements, and the supplemental guidance names contractors that provide "system development" among them.

The entity's SSPP has rows for SI-2, RA-5 and CM-8, and part of the evidence for them can only come from whoever builds the software.

What changed from MARS-E 2.2

MARS-E 2.2 (the AE System Security and Privacy Plan, dated 23 February 2021) was built on an older revision of NIST SP 800-53. Volume I of ARC-AMPE notes that MARS-E started when SP 800-53 was on its third revision and that ARC-AMPE was published against the fifth. CMS built the ARC-AMPE system-level control sets from the NIST SP 800-53B moderate baseline and tailored them.

For a vendor, the rows that matter changed like this:

First, the scanning clock did not simply loosen. RA-5 still requires a scan whenever a new vulnerability is reported that could affect the system, and advisories for software components land every day. A monthly scan with nothing in between misses that trigger.

Second, the patch clock got clearer but has an internal tension. SI-2 item c says to install security-relevant updates within 30 days of their release. The supplemental guidance and RA-5 item d allow 90 days for moderate and a year for low. Read conservatively: if an update fixes a security flaw and it is available, plan to ship it within 30 days, and use the longer windows only for findings that need more than an upgrade. Ask the entity which reading its SSPP uses, and write it down.

Which controls require a component inventory, supplier identification and provenance

CM-8, system component inventory

ARC-AMPE CM-8 asks for an inventory that accurately reflects the system, includes all components, avoids double counting, is granular enough for tracking and reporting, and records a specific list of fields. That list includes each component's unique identifier, the manufacturer and model, "Application software version/license information", the component owner and its operational status. The inventory must be reviewed and updated at least every six months.

Two enhancements are in the AE baseline. CM-8(1) says to update the inventory as part of installations, removals and system updates. CM-8(3) asks for automated detection of unauthorized hardware, software and firmware with a maximum five minute delay, and for disabling, isolating and notifying when something is found.

Most of CM-8 is written for servers and devices. The software rows are where a vendor helps. A CycloneDX or SPDX SBOM for each release gives the entity name, version, licence and identifier for every library inside your product, which a host inventory cannot see.

SR-2 and SR-3, the supply chain plan and processes

SR-2 asks the entity to write a supply chain risk management plan covering research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance and disposal, and to review it at least once a year. SR-2(1) asks for a team to run it.

SR-3 asks for a process to identify and address weaknesses in supply chain elements and processes, for supply chain controls that limit harm from supply chain events, and for those processes to be documented in the security and privacy plans and the SCRM plan. Its supplemental guidance adds a sentence that matters for vendors: the supply chain controls are "not limited to those defined in ARC-AMPE," and the organization should select other SP 800-53 Rev. 5 supply chain controls as appropriate.

SR-8, notification agreements

SR-8 asks for agreements with entities in the supply chain covering notification of supply chain compromises, results of assessments or audits, and organization information. If your contract does not already say how and when you tell the entity about a compromised dependency or a failed assessment, expect this row to produce a contract amendment.

SR-4 provenance is not in the AE baseline

The planning notes for this post listed SR-4 (provenance) as an ARC-AMPE control. It is not in the AE mandatory baseline in workbook 1.02, and neither is SR-11 (component authenticity). An entity can still add them. The workbook has an Entity-Specific Tailoring sheet, under PL-11 baseline tailoring, for added or tailored controls, and SR-3's guidance points the same way. So provenance may reach you as a tailored control or as a contract term, not as a baseline row. Our post on NIST SP 800-53 SR-4 provenance covers what the control asks if it does.

SA-15, SA-11, SA-22 and SI-7 on the development side

Three System and Services Acquisition controls reach straight into how you build:

• SA-15 requires the developer to follow a documented development process that addresses security and privacy, identifies the standards and tools used, and documents tool options and configurations, with a review at least yearly.
• SA-11(1) requires the developer to use static code analysis tools and document the results.
• SA-22 says to replace components when the developer, vendor or manufacturer stops supporting them, or to document justification and approval for continued use. The supplemental guidance requires that justification on a risk acceptance form, an updated POA&M entry, and a plan to upgrade, retire or stop using the component before end of life.

SI-7 adds integrity verification for software and firmware, and SI-7(1) asks for integrity checks. Component hashes in your SBOM give the entity something to check delivered artifacts against.

What an SBOM should carry in 2026

ARC-AMPE does not use the word SBOM. CISA and its co-authoring agencies published the 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026, replacing the 2021 NTIA list. New elements include SBOM Author Signature, SBOM Generation Context, Component Hash Value and Component License, and SBOM Author is now distinct from Component Producer. Those fields map onto CM-8's identifier and licence rows and SR-3's need to know who supplied what.

What remediation timelines apply, and how do KEV listings affect them

The ARC-AMPE clocks

The AE baseline puts the numbers in two places. RA-5 item d says to remediate legitimate vulnerabilities found by scanning within these windows: critical 15 calendar days, high 30, moderate 90, low one year. SI-2's supplemental guidance repeats them for flaws, and SI-2 item c adds the 30-day window for installing security-relevant updates after release.

SI-2 also says:

• Updates must be tested for effectiveness and side effects before installation, and the supplemental guidance suggests a test bed.
• If a patch will not be applied, or a legacy component the vendor no longer maintains stays in use, the organization must do a risk analysis and record a written decision from the CIO or a designee.
• The requirements apply to all components "for which a patch or work-around exists" for each vendor-identified or CVE or CWE-identified vulnerability.
• SI-2(2) asks for automated checks, at least monthly, that security-relevant updates are installed. SI-2(4) says patching must occur at least monthly, with validation in a lower environment first. SI-2(6) says to remove previous versions after an upgrade.

What the clocks do not say

ARC-AMPE does not say which severity rating to use. MARS-E 2.2 tied SI-2 to the NVD severity rating. The ARC-AMPE AE rows just say "rated as Critical severity." RA-5 item b asks for standards that measure vulnerability impact, so CVSS is the natural reading, but whose CVSS (NVD, the package's own advisory, a vendor bulletin) is left to the entity. Agree on it in writing and use the same source every month.

ARC-AMPE also does not say when the clock starts for a scanning finding. SI-2 counts from the release of an update. RA-5 counts from identification. For a library in your product, those dates can be weeks apart. Record both.

Where KEV fits

KEV does not appear in ARC-AMPE. What does appear is SI-5, which asks the entity to receive security alerts, advisories and directives on an ongoing basis, and names CISA as one source. CISA's Known Exploited Vulnerabilities catalog is the most direct of those signals: every entry is a CVE that has been seen exploited.

The federal directive built on KEV is now BOD 26-04, issued 10 June 2026. It revoked and superseded BOD 22-01 and BOD 19-02, and it sets remediation urgency from four variables: whether the asset is publicly exposed, KEV status, whether exploitation can be automated, and whether exploitation gives partial or total control. BOD 26-04 binds federal civilian executive branch agencies. By its own text it does not apply to contractors unless the procurement contract says so, and it does not bind state agencies.

So for a vendor to a state Medicaid agency, KEV is not a legal clock. It is the best input for ordering work inside the ARC-AMPE clocks. A sensible reading:

FIRST describes EPSS as a model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days. That 30-day horizon lines up well with the ARC-AMPE high window. Our post on keeping a contract promise of no known exploited vulnerabilities covers how to write KEV into a contract if the entity asks for it.

How do vendors feed the entity's SSPP and its continuous monitoring

The SSPP has rows with owners

The AE Volume II workbook is a spreadsheet. Each control row has the ARC-AMPE control text, supplemental requirements, related controls, a master control status, a control implementation description, and, since version 1.02, columns for a primary owner and up to five more owners, each with its own status and description. That structure is an invitation. Where your product carries part of a control, the entity can name you as an owner on that row and paste your text into the description.

Rows where a software vendor usually owns part of the implementation:

CM-8 for the components inside your product, RA-5 for findings in your releases, SI-2 for the fixes you ship and when, SA-11(1) and SA-15 for your development process, SA-22 for support status, and SR-3 and SR-8 for your suppliers and notification promises.

Write those descriptions in testable language: what you do, how often, with what tool, and where the evidence lives.

Continuous monitoring and what goes to CMS

Volume I says continuous monitoring must start immediately once CMS approves the authorization, and that the entity and its auditor submit evidence on the timelines in the ISCM guide for that user type. Table 4 of Volume I lists the artifacts CMS can ask for, including the SSPP itself, the POA&M, penetration test results, the Security Assessment Report and vulnerability scans.

The AE baseline makes the cadence concrete:

• CA-7 asks for scans of operating systems, databases and web applications at least once a month, control effectiveness assessment at least yearly, and status reporting at least every 30 days.
• CA-5 says the POA&M must include all findings, whether self-discovered or from assessments, with scheduled completion dates and milestones, and must be remediated consistent with SI-2. AEs deliver it to CMS quarterly on 31 January, 30 April, 31 July and 31 October.
• RA-5 says scan findings go into the POA&M and that scans are delivered to CMS on the same quarterly dates.

A useful vendor package each month, timed to land before the entity's monthly status report:

1. The SBOM for each release in production at the entity, with its date and version.
2. The vulnerability list for each, with severity, KEV status, fix version and decision.
3. The fixes shipped that month, with the date each finding was identified and the date the fix released.
4. Open items past or near their window, with a proposed POA&M milestone.
5. Any component that lost support, with your replacement plan.
6. Unaltered raw scan output, because RA-5 asks for it.

Our post on FedRAMP continuous monitoring covers the same monthly rhythm in a federal setting, and the GovRAMP and TX-RAMP vulnerability evidence post in this series shows how one package can serve several state buyers.

How should inventory and vulnerability evidence be shared without emailing files

A component inventory with vulnerability status is a map of what to attack. ARC-AMPE SA-4 item f asks contracts to include requirements "for protecting security and privacy documentation," and the MARS-E 2.2 SSPP carried a "For Official Use Only" marking on every page. A spreadsheet of unpatched components in a shared inbox fails that test.

A better channel has named recipients, expiry on every link, download limits or view-only access, revocation when a state project lead changes, and a record of who viewed and downloaded what. Agree the channel with the entity and write it into your SR-8 notification terms.

How Safeguard does this job

Safeguard covers the software supply chain part: what is in each release, which known vulnerabilities affect it and how urgently, whether a release met your rules, the fix, and a controlled handover. It runs against your code and build artifacts and never needs applicant data.

Step by step

1. Draw your software boundary. List the repositories, container images and release packages that run inside the entity's ACA boundary. Leave out anything that holds or could hold consumer PII: production extracts, logs, backups and test fixtures copied from real applications.

2. Connect your repositories and images. In the web app, open Integrations from the sidebar. Safeguard's docs list source code integrations for GitHub, GitLab, Bitbucket and generic Git, and container sources including Amazon ECR, Docker Hub and OCI registries. For each repository you set the branch or tag, Project Name and Version. Name them after what the entity runs, so a finding points to a release the assessor can recognise.

3. Or scan locally with the CLI. The CLI is GA. If the code cannot leave your build network, the docs give this flow:

   # Install the CLI
   curl -fsSL https://cli.safeguard.sh/install | bash
   # Open the terminal, then type /login and /scan .
   safeguard
   # Or scan from the command line, writing results under ./output
   safeguard scan --dir .
   

   According to the docs, a scan from the interactive terminal while signed in uploads the SBOM and findings to the platform, and the source never leaves the machine.

4. Generate the SBOM for each release. SBOM generation and analysis is GA, in SPDX and CycloneDX. The generation options in the docs include Project Name, Version (auto-detected from git tags), Branch or Tag, Include Dev Dependencies and Deep Analysis. Leave dev dependencies out of the SBOM you hand the entity unless they ship. This SBOM is your CM-8 software inventory and SR-3 supplier list in one file.

5. Keep scanning between releases. Software composition analysis and vulnerability management are GA. Safeguard's docs say every project is rescanned daily as new vulnerabilities are disclosed, and you can add triggers on push, on a schedule (daily, weekly or custom) or on release when a new tag is created. That gives you dated evidence for RA-5's 30-day cadence and, more important, for its "when new vulnerabilities are identified" trigger.

6. Triage by exploitation, then reachability. The Vulnerabilities tab groups findings as Critical, High, Medium, Low and Exploitable, where Exploitable means known active exploitation in the wild. Each finding shows the CVE, CVSS score, EPSS score, whether it is actively exploited (from the CISA KEV catalog), the affected component and version, the fixed version, references and reachability. Filters cover severity, CVSS and EPSS ranges, exploitable status, fix availability and reachability. Reachability analysis is GA, including static reachability for Ruby, PHP and Swift or Objective-C. Order work as in the KEV table above.

7. Record decisions the assessor will ask about. Mark False Positive takes a justification and can require approval. Accept Risk takes an expiration date and a business justification and goes for approval. Those records feed the entity's POA&M under CA-5, and for unsupported components they back the risk acceptance form that SA-22 asks for.

8. Turn your windows into policies and a release gate. Policies, gates and guardrails are GA. Under Settings, then Policies, Create Policy lets you set conditions on vulnerability severity, CVSS score, EPSS score, licence, component age and maintenance, with the visual builder or YAML. Templates include No Critical Vulnerabilities and No Abandoned Packages. Each policy's action is Block, Warn or Notify. With policy outcomes on for your workspace, the docs show a CI step that fails the job when a gate fails:

   safeguard ci scan --wait --fail-on-gate <gate>
   

   Exceptions need a request with justification, an approver and an expiration date, and leave an audit trail. A blocking gate on critical findings is how you keep a 15-day clock from being reset by the next merge. Our post on proving every production release passed a security gate covers the gate record.

9. Map findings on the NIST SP 800-53 framework page. The compliance and GRC suite is GA. There is no ARC-AMPE framework page, so map through NIST SP 800-53, which ARC-AMPE is built on. The page is on in your workspace unless you switch it off in Compliance, then Manage. Each scan of a product checks these scan-decided requirements:

   Safeguard requirement	What the scan checks	ARC-AMPE AE row it supports
   NIST53-CM-8	An inventory of components that reflects the system	CM-8
   NIST53-CM-8-3	Each component recorded with name and version	CM-8 granularity
   NIST53-SI-7	Cryptographic hashes for delivered components	SI-7
   NIST53-SR-4	Provenance, including who created the inventory	Not in the AE baseline; supports a tailored SR-4 or SR-3
   NIST53-SR-3	The supplier of each component known and recorded	SR-3
   NIST53-RA-5	Standard identifiers (PURL or CPE) so components match vulnerability databases	RA-5
   NIST53-SI-2	Known versions for every component so patches can be determined	SI-2

   The page's control catalog also lists RA-5, SI-2 and SR-3 among others, to evidence with automated tests, uploaded evidence, policies or an attestation. ARC-AMPE parameters, such as the 15-day critical window and the quarterly delivery dates, are yours to map.

10. Fix, then rescan. Autonomous remediation is GA, and it ships switched off with every category set to Manual. With it enabled, AI Remediate on the Vulnerabilities page generates remediation plans and fix pull requests, and View Fix shows upgrade options with breaking change warnings. Your engineers review and merge, and SI-2 item b still applies: test the update in a lower environment before it reaches the entity. After the fixed release builds, rescan it so the finding closes with a date.

11. Export the monthly package. Bulk export is GA, in formats including CSV, Excel, PDF, JSON and XML. Export the SBOM, the vulnerability list with decisions, the gate results and the framework page results for each release in production at the entity.

12. Publish and share through Portal, not email. Portal, the SBOM publish and share product, is GA. Publishing moves an SBOM from your scanning workspace into Portal as an immutable copy; sharing hands that copy on as it is. The sharing docs describe direct shares to named recipients with View, Download or Full permission, links with expiration, download limits and password protection, sharing restricted to approved domains, optional NDA acceptance, immediate revocation, and tracking of who accessed which SBOM. Portal's audit trail, under Settings, then Audit Logs, records views, downloads, sharing events and permission changes with timestamp, actor and result, and exports to CSV, JSON or PDF. Do this in the web interface.

13. Run it where the entity is comfortable. On-prem and air-gapped deployment are GA, as is Zero AI mode, which runs the platform with no language model in the loop.

Requirement, what Safeguard does, what you still own

What stays with the entity and its assessor

Most of ARC-AMPE has nothing to do with your dependencies, and the entity keeps all of it:

• The SSPP. The entity owns the workbook, decides which rows name you as an owner, and signs it.
• Categorization and control selection. Volume I's RMF table assigns categorization and control selection to CMS and implementation to the ARC-AMPE user.
• The assessment. Volume I says entities may be required to retain an independent third-party auditor who assesses the Volume II controls and reports to CMS using CMS templates. The Security Assessment Plan and Report are the auditor's.
• The authorization. CMS decides whether to grant the connection to the Hub, documented in the Interconnection Security Agreement.
• Privacy controls. The PII processing and transparency family, privacy impact assessments and data use agreements belong to the entity's privacy office.
• The quarterly deliveries. Scans and POA&Ms go from the entity to CMS. Your package feeds them.

What Safeguard does not do

• It is not an assessor and holds no CMS authorization. Safeguard cannot assess ARC-AMPE controls, sign an SSPP, issue a Security Assessment Report or speak for CMS. There is no ARC-AMPE framework page; mapping runs through NIST SP 800-53.
• It does not handle consumer PII in this flow. Do not point it at systems or data that hold applicant records. The scan targets are source code, build output, container images and SBOMs.
• It covers software components, not the rest of the boundary. Host inventory, network devices, operating system patch levels, configuration baselines, the five-minute unauthorized device detection in CM-8(3), and the monthly OS, database and web application scans in CA-7 need other tools. SAST and DAST are generally available and are not part of this flow.
• It does not decide your windows or your severity source. The policies enforce whatever you configure. The entity's reading of SI-2 and RA-5 decides what you configure.
• It does not confirm vendor support status. Component age and maintenance conditions are signals. Whether a producer still supports a version is a fact you confirm with the producer for SA-22.
• Its own certifications are not your evidence. Safeguard's architecture is designed for FedRAMP High, and it does not hold a FedRAMP authorization. It is SOC 2 Type II compliant. None of that substitutes for your controls or the entity's assessment.

Common mistakes

• Treating the 30-day scan as the only scan. RA-5 also triggers on newly reported vulnerabilities. A clean monthly report with a known critical sitting in the gap is still a finding.
• Citing MARS-E rows in a 2026 SSPP. Volume I says ARC-AMPE replaced MARS-E on publication. Old control numbers and the old 72-hour language confuse assessors.
• Writing "SR-4" into the plan because a template said so. Check the workbook. Provenance is not in the AE baseline unless the entity tailored it in.
• Not agreeing on a severity source. An NVD score and a package advisory score can differ by a full band, which moves the window from 30 days to 15.
• Counting from the scan date only. SI-2 counts from the release of the update. If the fix shipped upstream three weeks before your scan found it, you have one week left on a 30-day window.
• Letting unreachable findings lapse. Reachability ranks the queue. It does not exempt anything from ARC-AMPE's clocks unless the entity records a risk decision.
• Emailing raw inventories. An unpatched component list in an inbox is the kind of security documentation SA-4 says to protect.
• Forgetting SA-22 paperwork. Keeping an unsupported library without a risk acceptance form and a POA&M entry turns a known tradeoff into a control failure.

FAQ

When did ARC-AMPE replace MARS-E?

Volume I says ARC-AMPE supersedes and replaces MARS-E on publication. CMS lists Version 1.0 with a release date of 4 March 2025 and a compliance date of 4 March 2026 for ACA Administering Entities.

Does ARC-AMPE apply to software vendors?

Not directly by name. It applies to Administering Entities and select Partner Entities, and they bind vendors by contract. 45 CFR 155.260(b)(2) requires those contracts to pass the same privacy and security obligations to downstream entities, and ARC-AMPE SA-4 and SA-9 require contract language for developers and service providers.

What are the ARC-AMPE vulnerability remediation timelines?

The AE baseline sets critical at 15 calendar days, high at 30, moderate at 90 and low at one year. SI-2 also requires security-relevant updates to be installed within 30 days of their release.

How often does ARC-AMPE require vulnerability scanning?

RA-5 requires scanning every 30 calendar days and whenever new vulnerabilities that could affect the system are identified and reported. CA-7 asks for monthly scans of operating systems, databases and web applications. Administering Entities deliver scans to CMS quarterly.

Does ARC-AMPE require an SBOM?

No. Neither Volume I nor the AE workbook uses the term. CM-8 asks for an inventory that includes application software version and licence information, and SR-3 asks for supply chain processes, so an SBOM is the practical evidence for the software part of both.

Does ARC-AMPE use the CISA KEV catalog?

Not by name. SI-5 requires receiving security alerts and advisories from sources such as CISA. KEV is the most direct of those signals and a good input for ordering work inside the ARC-AMPE windows. BOD 26-04, which builds on KEV, binds federal civilian agencies, not state agencies or their contractors unless a contract says so.

What supply chain controls are in ARC-AMPE?

The ACA Administering Entity baseline includes SR-1 policy and procedures, SR-2 the supply chain risk management plan, SR-2(1) the SCRM team, SR-3 supply chain controls and processes, SR-8 notification agreements and SR-12 component disposal. Entities can add other SR controls through tailoring.

Is there an ARC-AMPE certification for software products?

No. CMS authorizes an entity's connection to the Hub based on its evidentiary artifacts. There is no product certification, and a vendor or tool claiming one is overstating it.

Getting ready before the next quarterly delivery

The next AE delivery date is 31 January 2027. Work back from it: SBOMs for every release running at the entity, known vulnerabilities with decisions, identification and release dates for every fix in the last 90 days, and support status for anything old. Agree the severity source and clock start in writing, then set a gate so the windows hold.

If you want to try the flow on your own code, download Safeguard from safeguard.sh/download and read the Safeguard documentation. For the underlying controls, see our posts on CM-8 component inventory, SR-3 supply chain controls, SI-2 flaw remediation and RA-5 vulnerability scanning. Other state programmes in this series: IRS Publication 1075 and CJIS Security Policy.

ARC-AMPE's 15 and 30 day windows keep running while an upstream maintainer works on a fix, so the waiting time comes out of your budget, not theirs. The section below covers what Safeguard offers when a fix exists but has not reached your build, and when upstream has no fix yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a session in the Safeguard desktop app. The CLI session appears in the conversation list, you ask for work on your computer, choose the folder, then Approve or Deny each command and file edit, and the session ends with a dependency upgrade done and tests passing. For an ARC-AMPE vendor, that approved and tested change is the start of an SI-2 record: a dated fix your team reviewed before it reached a release.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. Safeguard is listed in the Claude connector directory as a community connector, and the MCP server is GA. A compliance lead preparing the monthly package could ask an assistant which critical findings are past 10 days, and get an answer drawn from the same project data the assessor will see.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CMS: Marketplace Regulations and Guidance, ARC-AMPE section
• CMS: ARC-AMPE Volume I, Version 1.02 (PDF)
• CMS: ARC-AMPE ACA Administering Entities Volume II System Security and Privacy Plan, Version 1.02 (XLSX)
• CMS: MARS-E 2.2 Volume II, ACA Administering Entity System Security and Privacy Plan (PDF, history)
• eCFR: 45 CFR 155.260, Privacy and security of personally identifiable information
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA and partners: 2026 Minimum Elements for a Software Bill of Materials (PDF)
• FIRST: Exploit Prediction Scoring System (EPSS)
• Safeguard Docs: NIST SP 800-53 framework
• Safeguard Docs: Generate SBOM
• Safeguard Docs: Vulnerabilities
• Safeguard Docs: Policies and Gates
• Safeguard Docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard Docs: Portal Sharing
• Safeguard Docs: Portal Audit Trails
• Safeguard Docs: Compliance

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.