MARS-E and NIST 800-63 for Fraud Platforms: A State Exchange Roadmap

A state-based marketplace tells you they want your fraud platform. Then the security team sends a questionnaire that names MARS-E controls, asks for your NIST 800-63 identity assurance level, and mentions a "FedRAMP preference" before anyone has looked at a single detection screenshot. The technical eval you prepared for is not the gate. Compliance is.

Here is the direct answer to what most vendors ask at this point: SOC 2 Type II gets you the meeting, MARS-E gets you the contract, NIST 800-63 governs how you prove applicant identity, and StateRAMP or FedRAMP is what lets you sell the same system across many states. You sequence them in that order. You do not chase FedRAMP first because a state RFP used the word "preference."

I have watched vendors burn 18 months and low six figures pursuing certifications in the wrong order, ending up FedRAMP-adjacent but unable to answer a basic MARS-E control question. This is the roadmap I wish those teams had started with.

The Procurement Wall Nobody Warns Vendors About

MARS-E is not optional decoration. It is the mandatory security and privacy control baseline for Administering Entities under the Affordable Care Act and any contractor whose systems touch Exchange data or connect to the Federal Data Services Hub. CMS issues it. If your platform ingests applicant data from a state marketplace, you are in scope whether you signed up for it or not.

The wall trips vendors because the buying signal and the compliance signal arrive together. A program-integrity director loves your document forensics demo. Her security officer, in the same week, sends a 300-line questionnaire mapped to MARS-E 2.2 control families. If you cannot speak that language, the enthusiasm cools while your competitor with a mapped control library answers in four days.

The good news: these frameworks overlap heavily because most of them descend from the same NIST source. You are not building five separate compliance programs. You are building one and presenting it five ways.

What Each Standard Actually Governs

Confusion here costs real money, so pin down what each framework actually controls before you spend a dollar.

MARS-E 2.2 is the CMS-issued Minimum Acceptable Risk Standards for Exchanges. It is a tailored control catalog derived from NIST 800-53, plus privacy overlays specific to ACA data. It applies to state exchanges, Medicaid agencies acting as Administering Entities, and their downstream contractors [1].

NIST 800-63-3 is the Digital Identity Guidelines. It splits assurance into three axes: Identity Assurance Level (IAL) for proofing, Authenticator Assurance Level (AAL) for login strength, and Federation Assurance Level (FAL). IAL2 requires verified remote or in-person identity proofing tied to a real person [2].

SOC 2 Type II is an independent attestation, performed by a licensed CPA firm, that your security, availability, and confidentiality controls operated effectively over a monitored period, usually 6 to 12 months. It is not government-issued but it is the fastest credibility signal a commercial vendor can earn.

StateRAMP and FedRAMP are cloud security authorization programs. FedRAMP authorizes cloud services for federal agencies; StateRAMP does the equivalent for state and local government, with growing reciprocity where a FedRAMP authorization can satisfy StateRAMP requirements [3].

The pattern to notice: MARS-E, StateRAMP, and FedRAMP all inherit from NIST 800-53. Map a control once at the 800-53 level and it feeds all three.

Why IAL2 Is a Design Constraint, Not a Checkbox

IAL2 is where fraud platforms either shine or stumble, because remote identity proofing is exactly the problem you already solve. The 800-63A evidence chain requires collecting identity evidence, validating that the evidence is genuine and accurate, and verifying that the person presenting it is the true owner [2].

Read that again through a fraud lens. "Validate that the evidence is genuine" is document forensics. "Verify the person is the owner" is where synthetic-identity and SSN intelligence live. Your detection layers are not adjacent to IAL2. They are the mechanism that satisfies it.

For IAL2, you need at least one piece of strong evidence plus one piece of fair evidence, or two pieces of strong evidence, and each must be validated and bound to the applicant. A driver's license (strong) plus a paystub (supporting) is a common combination in enrollment. Document forensics catches the tampered license; SSN intelligence catches the fabricated, deceased, or reused number behind the identity.

Here is the shape of an identity-assurance decision flow that records IAL2 evidence in a form an auditor or a Medicaid Fraud Control Unit can actually use:

def assess_ial2(application):
    evidence = []

    # Document forensics: validate genuineness (800-63A validation)
    id_result = document_forensics.check(application.gov_id)
    evidence.append({
        "type": "government_id",
        "strength": "STRONG",
        "validation": id_result.tamper_score,   # 0.0 clean -> 1.0 altered
        "signals": id_result.detected_edits,
    })

    # SSN intelligence: verify binding to a real person (800-63A verification)
    ssn_result = ssn_intel.check(application.ssn, application.name, application.dob)
    evidence.append({
        "type": "ssn_binding",
        "strength": "SUPPORTING",
        "verification": ssn_result.status,       # valid / deceased / synthetic / reused
        "signals": ssn_result.flags,
    })

    score = program_integrity.score(evidence, application)

    if score.risk == "LOW":
        return decision("IAL2_MET", evidence, auto=True)
    else:
        # Route to a reviewer, never auto-deny
        return decision("HUMAN_REVIEW", evidence, auto=False)

The auto-deny is deliberately absent. IAL2 proofing that silently rejects legitimate applicants creates a civil-rights and access problem, not just a fraud problem. Every elevated-risk case routes to human-in-the-loop review so a person confirms the finding before anyone loses coverage. That review record is also your defensible audit trail: who decided, on what evidence, and why.

The Sequencing Order That Saves 18 Months

Sequence by which buyer requirement each certification unlocks, not by prestige. FedRAMP sounds impressive and belongs last for most fraud vendors.

Phase 1: SOC 2 Type II. This is your fastest path to a security team saying yes to a pilot. It forces you to write down your controls, and those controls become the foundation everything else maps to. Start the observation period early; you cannot compress a Type II audit period after the fact.

Phase 2: MARS-E control mapping and a System Security Plan. Once SOC 2 controls exist, map them to MARS-E 2.2 and draft an SSP aligned to the state's Administering Entity obligations. This is what converts pilot interest into a signable contract for anything touching Exchange data.

Phase 3: NIST 800-63 IAL2/AAL2 in the product. Bake identity assurance into the progressive trust model rather than bolting on a separate proofing vendor. If your fraud engine already validates documents and SSNs, you are most of the way to IAL2 evidence generation.

Phase 4: StateRAMP, then FedRAMP only if forced. Pursue StateRAMP when you are scaling across multiple states and they demand authorized cloud posture. Pursue FedRAMP only when a federal system connection or an explicit CMS mandate requires it. Chasing it early is how vendors lose 18 months.

Build One Control Library, Not Five Audit Programs

The expensive mistake is running parallel audit programs, each with its own spreadsheet, evidence folder, and owner. You end up collecting the same access-review screenshot three times for three frameworks.

Do this instead: map each control once against NIST 800-53 Rev 5, then inherit that control into MARS-E, SOC 2, StateRAMP, and FedRAMP. Because MARS-E and both RAMPs derive from 800-53, a single well-documented control (say, AC-2 account management) satisfies the equivalent requirement in every framework at once.

Use OSCAL, the NIST Open Security Controls Assessment Language, to keep control mappings machine-readable so you can generate framework-specific views instead of maintaining separate documents [4]. Pair it with evidence-collection automation that pulls access reviews, vulnerability scans, and change logs on a schedule so evidence stays fresh instead of being reconstructed the night before an assessment.

The traps that catch teams who assume 800-53 alone is enough:

• MARS-E-specific additions. CMS layers privacy and ACA-specific requirements on top of 800-53. Mapping to base 800-53 gets you most of the way, not all of it.
• Continuous monitoring. MARS-E and both RAMPs require ongoing monitoring, not a one-time audit. Point-in-time evidence will fail a reassessment.
• Interconnection Security Agreements. Connecting to the Federal Data Services Hub or a state system involves connection security agreements and specific data-handling terms that live outside your control catalog.

A 90-Day Starting Plan and What to Track

You do not need a compliance department to start. You need an owner, an inventory, and a control library tool. Here is the first quarter.

Days 1 to 30: Foundation. Name a single compliance owner with authority to pull engineering time. Inventory every data flow that touches Exchange data, applicant PII, or the Hub, because scope defines cost. Pick a control library tool that supports 800-53 mapping and OSCAL export.

Days 31 to 60: Gap assessment. Run a MARS-E gap assessment against your current SOC 2 posture; if you have SOC 2 already, you will be surprised how much maps directly. In parallel, document your IAL2 identity flow end to end, including how document forensics and SSN intelligence produce proofing evidence.

Days 61 to 90: Draft and automate. Draft the System Security Plan skeleton against the MARS-E control catalog. Begin evidence automation so access reviews and scan results collect themselves. By day 90 you should be able to answer a state security questionnaire in days.

Frequently asked questions

Do I need FedRAMP to sell to one state? No. For a single state-based marketplace, SOC 2 Type II plus a MARS-E-aligned SSP is the practical requirement. FedRAMP becomes relevant when a federal system connection or a specific CMS mandate forces it.

Does SOC 2 satisfy MARS-E? No, but it accelerates it. SOC 2 gives you a documented control base; MARS-E requires mapping those controls to the CMS catalog plus ACA-specific privacy and continuous-monitoring obligations that SOC 2 does not cover.

Is IAL2 the same as multi-factor authentication? No. IAL2 is about proofing identity (proving the person is who they claim). AAL2 is about authentication strength (MFA at login). You typically need both, and they are assessed separately under 800-63.

Can FedRAMP authorization count toward StateRAMP? Often yes. StateRAMP recognizes FedRAMP authorizations for reciprocity, though state-specific requirements can still apply [3].

Metrics to track from week one

• Percent of controls mapped to 800-53 with framework inheritance recorded
• Evidence freshness: percent of control evidence collected within the last 30 days
• Open POA&M items: plan-of-action-and-milestones count and average age
• Time-to-answer on inbound security questionnaires, in business days

Where to Start This Week

Pick the one action that unblocks everything else: name your compliance owner and give them a data-flow inventory to complete. You cannot scope MARS-E, cost a SOC 2 audit, or design your IAL2 flow until you know exactly which systems touch Exchange data.

Start tracking one metric this week: percent of your controls mapped to NIST 800-53. That single number predicts how fast you can answer the security questionnaire that arrives right after your best demo, the same questionnaire that stalled every vendor who treated compliance as a later problem.

The procurement wall from the opening is not a wall if you built one control library that speaks every framework. Then the questionnaire is a form you fill out in an afternoon, and the technical eval you actually prepared for is the one that decides the deal.

References

[1] Centers for Medicare & Medicaid Services, "Minimum Acceptable Risk Standards for Exchanges (MARS-E) 2.0/2.2 Documents," CMS.gov. https://www.cms.gov/marketplace/resources/regulations-guidance

[2] National Institute of Standards and Technology, "NIST Special Publication 800-63-3: Digital Identity Guidelines," 2017 (still the operative baseline; 800-63-4 in draft). https://pages.nist.gov/800-63-3/

[3] StateRAMP, "StateRAMP and FedRAMP Reciprocity," StateRAMP.org, 2025. https://stateramp.org/

[4] National Institute of Standards and Technology, "NIST Special Publication 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations," and OSCAL project documentation, 2020/2025. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

[5] IBM Security, "Cost of a Data Breach Report 2025," 2025. https://www.ibm.com/reports/data-breach