MARS-E compliance assessment: where NIST alignment breaks down in state exchange environments
Geert WarmenbolApril 29, 2026
Key takeaways
MARS-E compliance assessment is primarily an authorization boundary and control inheritance documentation exercise — most NIST 800-53 practitioners underestimate how much of the CMS review is about the SSP, not the controls.
State exchange environments that inherit controls from CMS federal systems frequently misclassify partially inherited controls as fully inherited, creating undocumented implementation gaps that CMS reviewers catch during SSP review.
Encryption key management failures are the most consistent technical finding in MARS-E assessments: keys stored in environment variables and configuration files rather than dedicated KMS infrastructure, despite encryption at rest being documented as implemented.
Vulnerability scan pipelines configured for infrastructure endpoints routinely miss container base images and serverless function dependencies — environments with documented RA-5 compliance are running unpatched components outside the scan boundary.
CMS reviewers request raw configuration exports and scan outputs, not narrative summaries. Organizations that translate technical evidence into documentation packages before submission face follow-up requests that extend authorization timelines by months.
TL;DR
MARS-E sits on top of NIST 800-53, but the assessment is not a NIST 800-53 assessment. The CMS authorization process cares about boundary documentation, inheritance accuracy, and raw evidence in machine-readable formats. State exchange programs that run standard NIST gap analyses and then translate the results into MARS-E packages discover the translation does not hold — the control baseline maps, but the authorization requirements do not. The gaps that survive the longest in production MARS-E environments are not exotic. They are IAM drift, key management shortcuts, and scan coverage gaps in container infrastructure.
When the authorization package comes back
A state exchange program submitted its MARS-E authorization package after six months of preparation. The System Security Plan was 400 pages. Every NIST 800-53 control had a documented implementation statement. The vulnerability scan reports showed clean results across all in-scope systems. CMS returned the package for revision with seventeen findings. Fourteen of them were inheritance documentation issues: controls the state had marked as fully inherited from CMS that CMS had not designated as inheritable for that authorization boundary. The technical controls were fine. The boundary model was wrong. The revision cycle added four months to the authorization timeline.
This pattern repeats because NIST 800-53 practitioners who move into MARS-E work bring the right control knowledge and the wrong process model. NIST assessments are primarily about whether controls are implemented. MARS-E authorization is about whether the boundary is correctly defined and whether each control's implementation responsibility is accurately assigned across that boundary. The two activities look similar in a checklist. They require different work.
What MARS-E actually requires beyond the NIST baseline
MARS-E Suite 2.0 uses NIST 800-53 Rev 4 as its security control catalog, with CMS overlays that add requirements specific to health insurance exchange systems. The control catalog is familiar to any practitioner with NIST experience. What is less familiar is the CMS authorization process that wraps it.
The ARC-AMPE process — the Authorization to Operate pathway for state exchange systems — requires state programs to submit an authorization package that includes a System Security Plan, a boundary diagram, a data flow diagram, a hardware and software inventory, a POAM for open findings, and an inheritance documentation package. The inheritance package is where most packages fail on first submission.
CMS operates federal systems that state exchanges connect to: the Federal Data Services Hub, the Identity Management system, and others. Controls implemented at the federal layer can be inherited by state systems — but only for the specific controls CMS has designated as inheritable for that boundary, and only for the aspects of those controls CMS has implemented. A state system that lists AC-17 (Remote Access) as fully inherited because CMS manages the VPN infrastructure, without documenting the state-side remote access policy and user account management that the state must implement independently, has an incomplete SSP.
The CMS Minimum Security Configuration Standards add another layer. These are specific configuration requirements for operating systems, databases, web servers, and network devices used in MARS-E environments. They are more prescriptive than the NIST control language. A NIST assessment that confirms AC-3 access enforcement is implemented does not confirm that the CMS MSCS requirements for that system type are met.
Example
In assessments of state Medicaid systems pursuing MARS-E authorization, Vulnox finds that organizations with strong NIST 800-53 compliance programs consistently underestimate the MSCS layer. The NIST controls are documented and largely implemented. The CMS minimum configuration standards for specific technology components — Windows Server hardening, Oracle database configuration, F5 load balancer settings — have not been evaluated against the MSCS baseline. These are separate documents from the 800-53 control catalog and are not always reviewed by NIST-focused assessors.
MARS-E Suite 2.0 maps to NIST 800-53 Rev 4, not Rev 5. Organizations that have migrated their security programs to the Rev 5 control structure need to maintain a mapping layer for MARS-E purposes. CMS has published a crosswalk but has not formally updated MARS-E to Rev 5 as of the 2025 guidance cycle. Running a Rev 5-structured assessment and generating Rev 4-format evidence packages requires deliberate translation that automated compliance tools do not perform by default.
What state exchange assessments actually find
Assessment base: Vulnox MARS-E gap analysis and ATO readiness assessments, 2023 to 2025, covering state exchange systems, Medicaid management information systems, and CMS-connected state health IT environments.
IAM roles accumulate permissions through feature development and are never reviewed at the aggregate level
State exchange systems are built incrementally. Each sprint adds features. Each feature requires permissions. Each permission grant goes through an approval process. None of this is wrong in isolation. The problem is that access reviews under AC-2 and AC-6 examine role definitions against documented need, not effective permissions against the attack paths those permissions enable. After two years of incremental development, a service account that started with read access to one S3 bucket has been granted permissions across fifteen resources. No single grant was excessive. The aggregate permission set allows an attacker who compromises that service account to move laterally across most of the environment. MARS-E audits that review access control documentation without testing effective permissions and privilege escalation paths consistently miss this.
Automated IAM analysis that maps effective permissions — not stated role definitions — and identifies privilege escalation paths is the only way to catch this pattern systematically. Policy documentation review, which is how most MARS-E access control assessments are conducted, produces a clean finding against an environment with significant privilege escalation exposure.
Encryption key management is documented as implemented while keys live in environment variables
MARS-E SC-28 requires protection of information at rest and SC-12 requires cryptographic key establishment and management. In documented SSPs, state exchange systems describe encryption at rest using AES-256 and key management procedures. In production, Vulnox finds encryption keys stored in application configuration files, Kubernetes secrets accessible to overly broad service accounts, and environment variables in container definitions visible to anyone with describe permissions on the ECS task or EKS pod. The encryption algorithm is correct. The key storage is not. The compliance documentation describes the algorithm and says keys are protected. It does not describe where keys actually live.
An attacker who can read environment variables on a compromised container — a routine post-exploitation step — has the encryption key. The AES-256 encryption provides no protection because the key is co-located with the data it protects. This finding appears in environments that have passed multiple MARS-E audits because auditors review key management policy documentation rather than examining where keys are stored in production.
Vulnerability scan coverage excludes container base images and serverless function dependencies
MARS-E RA-5 requires vulnerability scanning of information systems and hosted applications. State exchange programs configure vulnerability scans against their infrastructure endpoints: EC2 instances, RDS databases, load balancers. Container-based workloads are typically scanned at the running container level, which reports the container's exposed services but does not inspect the base image layer. A container running a three-year-old Ubuntu base image with 47 known CVEs in system packages will pass an infrastructure scan that checks whether the application service is reachable and configured correctly. Serverless functions have the same problem: the function code may be current, but the runtime dependencies packaged with it are not scanned against the vulnerability catalog.
Scan coverage documented as comprehensive against MARS-E RA-5 requirements is technically accurate for the scan targets that were configured. The attack surface that exists in container base images and function dependencies is real, unscanned, and invisible to the compliance record. The MARS-E SSP says vulnerability scanning is implemented. It does not say what the scan targets are.
Why organizations with more compliance automation have worse MARS-E evidence packages
Common belief
Organizations that have invested in compliance automation platforms — tools that continuously monitor controls, generate evidence artifacts, and maintain audit-ready documentation — should be better positioned for MARS-E authorization than organizations relying on manual evidence collection.
What we found
In an ATO readiness assessment for a state Medicaid system, Vulnox found that the organization's GRC platform had generated 800 pages of formatted evidence artifacts. CMS's first revision request asked for the raw IAM export and the original vulnerability scanner output files. The GRC platform had not retained them. The organization had to re-run scans and re-export configurations, which required a change control cycle and delayed resubmission by six weeks.
In practice, compliance automation platforms optimize for evidence formats that work for SOC 2, ISO 27001, and FedRAMP. They generate clean, formatted, auditor-friendly documentation packages. CMS MARS-E reviewers do not want formatted documentation packages. They want raw outputs: IAM role exports in JSON, vulnerability scan results in XML or CSV, SIEM log queries with timestamps, configuration exports from system components.
Organizations with mature compliance automation have trained their teams to produce the formatted artifact. When CMS asks for the underlying data that artifact was derived from, those teams often cannot produce it quickly — or cannot produce it at all, because the automation platform ingested the raw data and output the formatted artifact without preserving the source. The revision cycle that results looks, from the outside, like a compliance program failure. It is actually an evidence pipeline architecture problem.
Manual evidence collection programs, because they are working directly with raw system outputs, often produce more usable MARS-E evidence even though they look less sophisticated.
What state exchange programs consistently miss in MARS-E scope
The Federal Data Services Hub connection boundary
Every state exchange system that connects to CMS federal systems does so through the Federal Data Services Hub. The connection requirements, encryption standards, and monitoring obligations for this boundary are specified in CMS connection agreements, not in the MARS-E control catalog itself. Organizations that assess their MARS-E compliance against the 800-53 control list without separately reviewing the Hub connection requirements miss a documented CMS obligation. Findings related to Hub connection configuration are among the most common items on CMS revision letters.
Legacy Medicaid system interfaces that predate MARS-E scope definition
State exchange systems frequently interface with legacy Medicaid Management Information Systems that were built before MARS-E applied to the state's exchange operations. The interfaces were created for operational necessity and were not included in the original MARS-E system boundary. Over time, these interfaces transmit personally identifiable information in both directions. The MMIS is outside the MARS-E boundary. The data flows are not. Assessors who review the MARS-E boundary as defined in the SSP without mapping actual data flows will not find these interfaces. The PII is moving in and out of the authorized boundary through connections the SSP does not acknowledge.
Contractor system access that has not been through the inheritance review
State exchange programs are built and operated by contractors. Contractor staff access state systems through remote access infrastructure that is sometimes managed by the contractor rather than the state. When this infrastructure is outside the MARS-E authorization boundary, remote access controls that MARS-E requires the state to implement are being implemented by a contractor in an unreviewed environment. The state's SSP documents remote access controls as implemented. The actual implementation is in a contractor-managed system that has never been through a MARS-E or equivalent review.
Where MARS-E compliance pressure is heading
CMS will update MARS-E to align with NIST 800-53 Rev 5 within two years, and the migration will expose control implementation gaps in state systems that were masked by the Rev 4 control structure — particularly in supply chain risk management, privacy controls, and zero trust alignment.
CMS has signaled intent to modernize the MARS-E framework. NIST 800-53 Rev 5 added the SR (Supply Chain Risk Management) control family, which has no direct Rev 4 equivalent. State exchange programs that have never assessed their software supply chain, third-party component libraries, or container base image provenance will face entirely new control requirements with no existing implementation to document. The Rev 5 privacy control integration also changes how PII handling is documented — the current MARS-E approach treats privacy as a data classification question, Rev 5 treats it as a control family with specific implementation requirements.
Confidence: highIf CMS does not publish a MARS-E Suite 3.0 or equivalent Rev 5-aligned update by 2028, or if CMS announces an extended timeline that pushes the migration past 2029.A state exchange system will experience a significant data exposure event directly attributable to a container base image vulnerability that passed all documented MARS-E vulnerability scanning requirements, creating pressure for CMS to add explicit container scanning coverage requirements to the RA-5 implementation guidance.
The gap between documented RA-5 compliance and actual container image vulnerability coverage exists in multiple state exchange environments simultaneously. Container base image patching is not consistently included in MARS-E scan targets. The vulnerability catalog entries for outdated base image packages are publicly available and actively exploited. The structural conditions for this event are present. The only variable is which environment is targeted first.
Confidence: mediumIf CMS issues updated RA-5 implementation guidance explicitly requiring container image scanning before a documented breach occurs, or if no state exchange breach is attributed to container base image vulnerabilities through 2028.
What state exchange programs say before assessments — and what the gap analysis finds
We passed our last MARS-E audit. Our controls are documented and implemented. We need a light-touch review before reauthorization.
Root cause:Authorization cycles are typically three years. In three years of continuous development, a state exchange system will have added features, changed vendors, deployed new infrastructure components, and modified access control configurations. The controls that were implemented and documented at the last authorization reflect the system as it existed then. IAM drift, new interfaces that were not added to the boundary diagram, and vulnerability scan coverage gaps that developed as infrastructure changed are not visible in the prior authorization package. The prior authorization confirms what was true three years ago.
Our vulnerability scans are scheduled weekly and show clean results. RA-5 is implemented.
Root cause:The scan results are clean for the targets the scans are configured to reach. Container base images, serverless function runtimes, and internal microservice dependencies are typically not in the configured scan target list. The scan automation is running correctly. The coverage boundary is wrong. Distinguishing between a clean scan and a comprehensive scan requires reviewing the scan target configuration, not the scan results.
Our SSP documents inheritance from CMS for all the shared controls. The inheritance section is complete.
Root cause:The inheritance documentation captures what the state program believes it inherits. CMS's current inheritance grants may not match. CMS updates the authorized inheritance template when federal system implementations change. State programs that have not reconciled their SSP inheritance claims against the current CMS inheritance template since the last authorization are documenting a state of inheritance that may no longer be accurate. This is the most common cause of CMS revision requests on MARS-E package submissions.
The MARS-E authorization process optimizes for the wrong output
The MARS-E ATO process produces a System Security Plan. The SSP is a document. CMS reviews the document. State programs optimize for producing a good document. The problem is that a good document and a secure system are different outputs, and the effort required to produce the document displaces effort that could go into actually improving controls. I have seen state exchange programs spend twelve months on an authorization package and three weeks testing the actual security of the system. The authorization timeline is real and the CMS review is real. But the thing that determines whether sensitive health insurance data is protected is not the quality of the SSP. It is whether the controls work. The authorization process does not reliably verify that.
Counterargument
The counterargument is that the SSP process forces explicit documentation of the authorization boundary, inheritance responsibilities, and implementation statements that many organizations would never produce otherwise, and that this documentation creates an accountability structure that improves control implementation over time. There is something to this — state programs that have been through multiple MARS-E cycles do tend to have more mature security programs than comparable state IT systems that have never been through a federal authorization process. The process is not useless. It is just not measuring what it claims to measure.
One thing to do before the next authorization cycle
Pull your current SSP's inheritance documentation and compare it against CMS's current authorized inheritance template for your boundary type. If your SSP was last updated more than eighteen months ago, there is a reasonable chance the inheritance claims have drifted from what CMS will authorize. Finding and correcting that drift before package submission costs a few days of documentation work. Finding it after submission costs months of revision cycles. That single check is the highest-return preparation step for most state exchange programs approaching reauthorization.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisUS federal cybersecurity frameworks: the complete guide to all 37 mandates
MARS-E compliance requirementsNational Vulnerability Database NIST
National Vulnerability DatabaseNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideUnderstanding Compliance Gap Analysis
compliance gap analysis guide
Frequently Asked Questions
What makes MARS-E compliance assessment different from a standard NIST 800-53 assessment?
MARS-E uses NIST 800-53 as its control baseline but layers CMS-specific requirements on top, including the ARC-AMPE authorization process, CMS minimum security configuration standards, and explicit data handling requirements for personally identifiable information and protected health information processed in state exchange systems. The inheritance model is the most operationally distinct feature: state exchanges inherit some controls from CMS federal systems but must independently implement and document others. Most NIST 800-53 practitioners underestimate how much of the MARS-E assessment is actually an authorization boundary and inheritance documentation exercise, not a control testing exercise.
What does CMS actually examine during a MARS-E compliance review?
CMS reviews focus on the System Security Plan and supporting artifacts: boundary diagrams, data flow documentation, inherited versus implemented control matrices, and the Plan of Action and Milestones for open findings. CMS reviewers request evidence in specific formats — they want configuration exports and scan outputs, not narrative descriptions of controls. The most common reason MARS-E authorization packages are returned for revision is incomplete inheritance documentation: the state system claims inheritance for controls the CMS authorizing official has not granted as inheritable for that boundary.
Which MARS-E controls have the highest failure rate in practice?
In Vulnox assessments of state exchange environments, the controls with the highest gap rate are: encryption key management under SC-28 and SC-12 (keys stored in configuration files or environment variables rather than dedicated key management infrastructure); privileged access management under AC-6 and AC-2 (overly broad IAM roles that have accumulated permissions through feature development without periodic review); and vulnerability scanning coverage under RA-5 (scans configured against infrastructure endpoints that miss container base images and serverless function dependencies). These three control areas account for the majority of significant findings.
How does MARS-E handle control inheritance between CMS federal systems and state exchange systems?
MARS-E's inheritance model divides controls into three categories: controls fully inherited from CMS (the state system relies entirely on CMS implementation), controls partially inherited (the state system inherits some aspects and must implement others), and controls fully implemented by the state system. The boundary is defined in the CMS inheritance template. States frequently misclassify partially inherited controls as fully inherited, creating gaps in the SSP where the state's own implementation layer is undocumented. CMS reviewers catch this during SSP review, but the correction cycle adds months to the authorization timeline.
What evidence format does CMS request during a MARS-E security review?
CMS expects configuration exports from SIEM and vulnerability scanning tools, not summary reports. For access control findings, they want IAM role export files showing actual permission assignments, not policy documentation. For vulnerability management, they want raw scan outputs with CVE identifiers, severity ratings, and timestamps — not a presenter's summary of scan results. For incident response readiness, they want tabletop exercise records or test results, not the IR plan document itself. Organizations that translate raw technical outputs into narrative evidence packages before submission typically face follow-up requests for the underlying data.
What is the most common MARS-E finding that survives multiple audit cycles undetected?
Overly permissive IAM roles that accumulated excessive permissions through incremental feature development. Each individual permission grant was justified at the time it was added. No single grant triggered a control failure. The aggregate permission set creates privilege escalation paths that standard access control reviews do not catch because those reviews examine role definitions rather than effective permissions and the attack paths they enable. In Vulnox assessments of state exchange environments, this pattern appears consistently in environments that have passed multiple annual MARS-E audits.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.