CYBER SECURITY COMPLIANCE · CMS EDE
CMS Enhanced Direct Enrollment
Audit Readiness for EDE Entities, Issuers and Web-Broker
Enhanced Direct Enrollment lets approved issuers and web-brokers host the HealthCare.gov eligibility application on their own sites, integrated through the Federally-facilitated Exchange API suite. It is also one of the most demanding audit regimes in health insurance technology: primary EDE entities undergo a third-party business requirements audit and a privacy and security audit, inside an annual submission window that does not move. Elevate Consult has worked with CMS EDE since 2018 and prepares entities for the privacy and security portion of the audit.
2026 UPDATE
What to know for the current audit year
CMS publishes audit guidelines by programme year
The guidelines governing third-party auditor operational readiness reviews are reissued each EDE year, and the current edition governs what auditors test and what documentation the package must contain. Confirm which programme year applies to your submission before building against a prior year’s toolkit, because baseline versions change.
Toolkit baselines land in the first quarter
CMS releases new baseline versions of the eligibility results toolkits, API functional integration toolkit, communications toolkit and business audit instructions in the first quarter, usually mid to late February. Starting the business requirements portion of the audit before those release means building against a superseded baseline.
The submission window is fixed and short
The audit submission window for prospective primary EDE entities and for entities changing phases runs annually from 1 April to 1 July at 3:00 AM Eastern. Development must be complete before the window opens, including integration with all required APIs.
CMS feedback takes two weeks or more
If a package is incomplete or testing was unsuccessful, the entity needs that feedback early enough to submit a corrected package inside the same window. That is the argument for submitting in early May rather than late June.
WHAT IT IS
Direct Enrollment and the Enhanced pathway
Classic Direct Enrollment allows approved Qualified Health Plan issuers and third-party web-brokers to enroll consumers in Exchange coverage from their own websites, but redirects the consumer to HealthCare.gov to complete the eligibility application and then back again. That multi-step handoff is where consumers drop off.
Enhanced Direct Enrollment removes the redirect. EDE entities build and host a version of the HealthCare.gov eligibility application directly on their sites, integrated through a suite of FFE APIs covering eligibility, enrollment and post-enrollment servicing. CMS released the implementing guidance in February 2018. Implementation runs in three phases, with Phase 3 covering all use cases.
The pathways are available only in states using the Federally-facilitated Exchange or the State-based Exchange on the Federal Platform model. The EDE programme does not extend to State-based Exchanges that do not rely on the Federal Platform, or to SHOP marketplaces.
ENTITY TYPES
Primary, upstream and downstream, and who gets audited
The audit burden depends entirely on entity type, and the distinction is the first thing to establish because it determines cost and timeline more than anything else does.
Primary EDE entity
Full audit
Builds the EDE platform. Must retain a third-party auditor, complete the business requirements audit and the privacy and security audit, sign the Interconnection Security Agreement and EDE Business Agreement, hold a unique Partner ID, and conduct oversight of upstream entities and downstream agents and brokers
Hybrid issuer (upstream)
Conditional
An issuer implementing additional functionality or systems beyond minor branding or display changes. Must sign an EDE Business Agreement and maintain a unique Partner ID.
Downstream agents and brokers
No audit
Use an EDE entity’s approved environment through the primary entity or an upstream arrangement. Do not sign the EDE Business Agreement or ISA and are not provided a unique Partner ID for EDE API transactions.
White-label issuer (upstream)
No audit
Uses a primary entity’s approved environment with minor branding and QHP display changes only. Not required to submit a business requirements or privacy and security audit, but must submit the DE Entity Documentation Package, sign the EDE Business Agreement and maintain a unique Partner ID.
Hybrid non-issuer (upstream)
Privacy and security audit
Agents, brokers or web-brokers using a primary entity’s environment with added functionality that changes the end-user experience. Must retain an auditor for a privacy and security audit covering the added functionality, sign the EDE Business Agreement and maintain
a unique Partner ID.
QHP issuers on the FFE
Separate path
Request DE participation by submitting a Hub Onboarding Form. Must meet CMS regulatory requirements, maintain a secure website, sign a QHP certification agreement, and implement the technical requirements to connect to the FFE.
OUR PROCESS
Audit readiness for the privacy and security portion
Elevate advises on how to meet the audit requirements for the privacy and security portion. Elevate never holds system access or privileges, which preserves independence from the process, while bringing the architecture knowledge that produces a platform capable of passing CMS review.
Test environment guidance
Structure test environments that mirror production across all EDE APIs, with change parity, and keep test data out of FFE production environments.
Privacy and security audit preparation
Advise on meeting the requirements for the privacy and security portion of the third-party audit, including evidence structure and documentation.
Continuous monitoring readiness
Establish the Information Security and Privacy Continuous Monitoring practices that carry through the year rather than reassembling before each audit.
Phase change support
Preparation for entities already approved who are implementing a new eligibility application phase, which reopens audit obligations.
Architecture readiness review
Assess the platform architecture against what CMS requires before the audit window opens, while there is still time to change it.
Risk assessment and SAR support
Support the risk assessment and the Security Assessment Report, including the operational evidence CMS expects for ongoing monitoring.
ENGAGEMENT PHASES
How the work runs
WHO THIS IS FOR
Roles Elevate works with on this standard
GET STARTED
Ready to prepare for your EDE audit?
Elevate Consult has worked with CMS EDE since 2018 and has supported clients through CMS approval. This is a niche area of competency, and the privacy and security portion of the audit is where most schedules slip.
FAQ
Common Questions
What is the difference between Direct Enrollment and Enhanced Direct Enrollment?
Classic DE lets an issuer or web-broker enroll consumers from their own site, but redirects the consumer to HealthCare.gov for the eligibility application and then back. EDE removes the redirect: the entity hosts a version of the eligibility application on its own site, integrated through the FFE API suite, and can provide post-enrollment servicing year-round without sending the consumer to HealthCare.gov.
Which entities have to be audited?
Primary EDE entities undergo both a business requirements audit and a privacy and security audit. Hybrid non-issuer upstream entities must retain an auditor for a privacy and security audit covering the functionality they add. White-label issuers making only minor branding and display changes are not required to submit either audit, though they still file the documentation package and maintain a Partner ID. Downstream agents and brokers are not audited.
When is the audit submission window?
It runs annually from 1 April to 1 July at 3:00 AM Eastern, for prospective primary EDE entities and for approved entities seeking a phase change. Development must be complete before it opens. CMS releases new toolkit baselines in the first quarter, usually mid to late February, and beginning the business requirements portion before those release means testing against a superseded version.
Where is EDE available?
Only in states using the Federally-facilitated Exchange or the State-based Exchange on the Federal Platform model. The programme does not extend to State-based Exchanges that do not rely on the Federal Platform, or to SHOP marketplaces. Confirm the current state list with CMS, because the set of states on each model changes between plan years.
Does Elevate access our systems during the engagement?
No. Elevate never holds system access or privileges, which preserves independence from the audit process. The engagement is advisory: how to architect a secure and operational platform that will meet CMS requirements, and how to structure the evidence the privacy and security audit will test.
How long does EDE implementation take?
Development and audit preparation frequently take a year or more, and the fixed annual window means a missed submission costs a full cycle rather than a few weeks. The constraint is rarely the API integration itself. It is having the infrastructure, operational processes and evidence of ongoing monitoring in place early enough to support the risk assessment and the Security Assessment Report.