CMS EDE audit submissions for Year 9 open on April 1, 2026. Prospective entities have a three-month window to submit complete audit packages before the July 1, 2026 deadline (3:00 AM ET). Building and auditing an EDE environment is a major lift, CMS notes the end-to-end process can take a year or more, especially when resubmissions are required.
CMS has also continued to refine operational and technical standards across PY 2026, so teams should plan for evolving requirements alongside implementation work. With the submission window approaching fast, preparation in March is no longer “early,” it’s on time.
This guide breaks down the audit requirements, technical integration steps, participation models, and the critical dates you must hit to implement CMS EDE successfully in 2026.
What is CMS Enhanced Direct Enrollment
CMS released detailed guidance for Enhanced Direct Enrollment in February 2018. This introduced a pathway that would fundamentally change how consumers interact with Marketplace coverage. The previous direct enrollment methods created a fragmented experience. Consumers had to navigate between multiple websites. EDE eliminates this problem.
EDE vs Classic Direct Enrollment Pathways
The Classic Direct Enrollment pathway will end after October 31, 2025. This includes all double redirect variations. Starting November 1, 2025, only Enhanced Direct Enrollment will be permitted for Federally-facilitated Marketplace enrollments. This represents a most important change in how CMS EDE partners operate.
Classic DE required consumers to quote and select plans on a web-broker’s site. The system then redirected them to HealthCare.gov to complete the official application. Once users finished the application and received their eligibility determination, the system redirected them back to the web-broker’s site. This back-and-forth process led many consumers to drop off during enrollment. Confusion and errors caused the problem.
EDE removes this friction entirely. The pathway provides a complete consumer experience. It has the eligibility application, Exchange enrollment, and post-enrollment year-round customer service capabilities directly on issuer and web-broker websites. Consumers can now complete their Exchange application and enrollment into an Exchange plan without visiting HealthCare.gov. Agents using outdated systems or partners who fail to transition to EDE before the deadline risk losing their capacity to enroll Marketplace clients.
Federally-facilitated Exchange (FFE) and SBE-FP Integration
The DE and EDE pathways are only available for states that use the Federally Facilitated Exchange or State-based Exchange on the Federal Platform. This totals 36 states. This coverage area defines where CMS EDE implementation applies.
EDE entities build and host a version of the HealthCare.gov eligibility application directly on their websites. This version securely integrates via a suite of FFE application programming interfaces. Through these API-based secure data transfers, the Federally-facilitated Exchange determines a consumer’s eligibility for health insurance through Exchange coverage, Medicaid, or the Children’s Health Insurance Program. The system also calculates the appropriate amount of advance payments of the premium tax credit and cost-sharing reductions.
The Exchange retains responsibility for making eligibility determinations. The Exchange communicates those eligibility determinations to the EDE entity via the EDE APIs. The EDE entity displays the results to the user on their website. Issuers continue to receive their 834 enrollment transactions for all enrollments from the Exchange. This happens whatever the enrollment is completed on an EDE entity website or on HealthCare.gov.
EDE API Suite Overview
Primary EDE entities that build an EDE platform are required to integrate with a suite of more than 20 APIs. These APIs support the eligibility, enrollment, and post-enrollment experience. This integration provides EDE entities with the data and tools necessary to manage customer relationships fully.
For Year 9 of EDE, the suite of required services has Store ID Proofing, Person Search, Create App, Create App from Prior Year App, Store Permission, Revoke Permission, Get App, Add Member, Remove Member, Update App, Submit App, Get Data Matching Issue, Get Special Enrollment Period Verification Issue, Metadata Search, Notice Retrieval, Submit Enrollment, Document Upload, System and State Reference Data, Get Enrollment, Payment Redirect, Update Policy, and Events Based Processing.
The APIs allow EDE entities approved to participate in EDE to create, modify, submit, and retrieve Exchange data. Consumers and agents can update applications when necessary. They can remedy open consumer Data Matching Issues and Special Enrollment Period Verification Issues. They can upload documents, view the status of data matching and Special Enrollment Period verification issues, and download notices from the Exchange.
There are three phases for implementation. Phase 3 covers all possible use cases and has Native Americans and dependents who are not daughters, sons, or spouses. Phase 1 entities can support only simple cases. Phase 2 entities can support common complex cases and has applicants who are pregnant, full-time students, or noncitizens.
Who Needs to Implement CMS EDE in 2026
Different entity categories must understand the CMS EDE implementation requirements for 2026. Each category has different technical and operational obligations. The category that applies to your organization determines the scope of your audit requirements, documentation needs, and approval timeline.
Qualified Health Plan (QHP) Issuers
Issuers providing QHPs on the FFE can request to participate in Direct Enrollment. They submit a Hub Onboarding Form. CMS provides additional instructions following this original submission. Issuers must meet regulatory requirements and maintain a secure website. They sign a QHP certification agreement with CMS and implement the technical requirements to connect with the FFE through the DE pathway.
A primary EDE Entity must have a third-party auditor and complete the business requirements. The entity needs privacy and security audits. It signs the ISA and EDE Business Agreement, has its own Partner ID, and complies with all applicable requirements. This entity conducts oversight of upstream EDE Entity and downstream agent and broker users of its approved EDE environment.
White-label issuers use a primary EDE Entity’s approved EDE environment but make minor branding and QHP display changes. These entities don’t need to conduct and submit a business requirements audit or a privacy and security audit. They must submit the applicable DE Entity Documentation Package and the EDE Business Agreement. They maintain a unique Partner ID.
Hybrid issuer upstream EDE Entities implement additional functionality or systems to the primary EDE Entity’s EDE environment. These go beyond minor branding changes or QHP display changes. These entities must sign an EDE Business Agreement and maintain a unique Partner ID.
Web-brokers and Technology Providers
Prospective web-brokers can request approval to enroll consumers in Exchange coverage through DE or EDE. They initiate the web-broker onboarding process. Web brokers may onboard year-round. The CMS EDE partners list had multiple approved web-brokers and DE technology providers operating approved platforms as of December 8, 2025.
Hybrid non-issuers are agents, brokers, or web brokers that use a primary EDE Entity’s EDE environment with additional functionality. This functionality changes the EDE end-user experience. These upstream EDE Entities must retain an auditor to conduct a privacy and security audit. The audit relates to the additional functionalities or systems they seek to add to the primary EDE Entity’s approved EDE environment. They must sign an EDE Business Agreement and maintain a unique Partner ID.
Agent and Broker Direct Enrollment Requirements
Licensed agents and brokers assist consumers in applying for insurance affordability programs. These programs offer the premium tax credit and cost-sharing reductions. Agents and brokers help consumers enroll in qualified health plans through the Marketplace. They play a vital role in educating consumers about the Marketplace during the annual Open Enrollment Period and throughout the plan year.
Agents and brokers should understand the standards under 45 CFR § 155.220 before assisting consumers. These standards authorize agents and brokers to assist consumers with selecting and enrolling in QHPs offered through the Marketplace.
An EDE Entity may allow third-party agents and brokers to use its approved EDE environment. This access can be direct through the primary EDE Entity or through an arrangement with an upstream EDE Entity. Downstream third-party agents and brokers will not sign an EDE Business Agreement or the ISA. They will not be provided or allowed to use a unique Partner ID for EDE API transactions.
Existing DE Entities Transitioning to EDE
CMS will discontinue Classic DE after October 31, 2025. This affects all double redirect pathways. Agencies and agents who do not switch to EDE risk losing their ability to enroll Marketplace clients. EDE Entities must decommission their classic DE pathways on or before October 31, 2025. Prospective and approved EDE Entities cannot access the consumer-facing or agent/broker-facing classic DE pathways in test or production environments after October 31, 2025.
Entities operating Phase 2 EDE pathways must refer consumers to the Marketplace Call Center or HealthCare.gov when they encounter scenarios that their Phase 2 platform cannot support. These entities will no longer have the option to redirect consumers to the classic DE pathway.
Entities may seek approval to participate in the EDE program in different ways. They can become a primary EDE Entity that has developed its own EDE environment. They can be an upstream EDE Entity leveraging an approved primary EDE Entity’s EDE environment. They can also be a downstream agent/broker using an approved primary or upstream EDE Entity’s EDE environment. Some of these options may require developing a technical platform to interface with the Exchange and implementing privacy and security controls. Entities must document these controls and submit documentation to CMS. This documentation should have third-party audits before approval.
2026 Implementation Timeline and Deadlines
Timeline management separates successful CMS EDE implementations from those that miss critical approval windows. The compressed submission period combined with extended development and approval cycles creates a challenging coordination effort for prospective entities.
Year 9 Audit Submission Window: April 1 – July 1, 2026
The audit submission window for prospective primary EDE entities and prospective phase change EDE entities runs from April 1, 2026 to July 1, 2026 at 3:00 AM ET. CMS will not review audits until the submission window begins. Entities must submit a complete audit that CMS designates as complete before the deadline to advance to the next phase of review.
Development work should finish well before April 1st. We recommend you complete environment development prior to the audit submission window start date. CMS can take two weeks or more to provide feedback on submitted packages. Entities cannot receive approval for completeness if the package lacks completeness or testing fails. Submitting early, such as early May, provides more time to submit another package that CMS will approve.
CMS encourages entities to submit complete audits as early as possible within the audit submission window. Your opportunities to correct completeness deficiencies depend in part on when you submit the audit. Earlier submissions allow more resubmission cycles before the window closes.
Approval Process Duration: What to Expect
Developing and auditing an EDE environment may take up to or more than a year. Once you submit a complete audit, the approval process involves multiple resubmissions on your behalf. Resubmissions may stem from compliance findings in the audit submission and resubmissions, plus issues and findings in the EDE environment and eligibility application.
The number of resubmissions and back-and-forth communication depends on how quickly you address issues and findings. The EDE approval process takes many months after an audit submission has been deemed complete. The process may take up to a year or more depending on your selected end-state phase, the quality of your EDE environment build, the quality of audit and documentation submitted to CMS, and the quality and timeliness of resubmissions.
There is no guarantee that every prospective primary EDE entity or prospective phase change EDE entity submitting a complete audit within the submission window will receive approval prior to the PY 2026 OEP or during the 2027 calendar year. Starting development right away becomes essential given these points. Book a Readiness Call to assess where your organization stands in the preparation timeline.
Last Business Day of June: ISA Submission Requirement
Approved primary EDE entities must submit the Interconnection Security Agreement by the last business day of June each year. This requirement applies whatever your original approval date. Also, upstream entity approval will only occur with or after the primary EDE entity’s approval.
Planning for PY 2026 Open Enrollment Period
The PY 2026 Marketplace Open Enrollment Period (OEP) for ACA plans ran from November 1, 2025 through January 15, 2026. Enrollments completed Nov 1–Dec 15 generally took effect January 1, 2026, while enrollments Dec 16–Jan 15 generally took effect February 1, 2026 (effective dates can vary by state exchange).
Now that OEP has already closed, the focus shifts to year-round operations and readiness for the next enrollment cycle. For CMS EDE entities, this means:
-
Maintaining production stability and ongoing compliance (including monitoring, vulnerability management, and audit readiness).
-
Supporting Special Enrollment Period (SEP) flows, post-enrollment changes, document handling, and notices.
-
Using what happened during OEP as a post-mortem to harden workflows, reduce friction, and fix any gaps in your EDE environment.
If your organization is preparing for Year 9 audits opening April 1, 2026, the goal isn’t to “make OEP”, it’s to get approved, stay compliant, and be fully operational well ahead of the next OEP, so you’re not racing the clock again.
Choosing Your EDE Participation Model
Your choice of participation model shapes every aspect of your CMS EDE implementation, from technical requirements to audit scope to approval timeline. The EDE ecosystem has multiple interconnected entities, and each plays a distinct role in supporting consumer access to health coverage through the Exchange. The Health Insurance Exchange system sits at the center and remains the authoritative source of truth for eligibility and enrollment data.
Primary EDE Entity: Build Your Own Environment
Primary EDE entities own and operate the underlying technology platform that provides consumers with plan shopping, selection, and enrollment services. These technology providers develop and maintain an EDE environment that communicates with the Health Insurance Exchange system through standardized Application Programming Interfaces to transmit eligibility and enrollment data.
Building your own environment means integrating with over 20 APIs that make eligibility and enrollment experiences possible. Your application and privacy/security structure must pass thorough third-party audits. This path just needs significant development resources and time. Developing and auditing an EDE environment may take up to or more than a year, so early planning becomes critical. Book a Readiness Call to determine whether building your own platform arranges with your timeline and technical capacity.
Upstream Arrangements: Using Existing Platforms
Upstream EDE entities employ a primary EDE entity’s platform with customized branding. All upstream EDE entities must have a legal relationship with a primary EDE entity reflected in a signed written agreement between the upstream EDE entity and the primary EDE entity. Therefore, only a primary EDE entity can provide an EDE environment to a hybrid non-issuer or issuer. Upstream EDE entities cannot provide an EDE environment to other upstream EDE entities.
Web-brokers without substantial development resources can reach the market faster by partnering with an approved primary EDE entity. Upstream entities assume the phase of their primary entity and are not permitted to support consumer enrollment scenarios beyond those supported by their primary entity.
White-label Issuer Implementation
White-label issuers employ a primary EDE entity’s technology platform and application while making only minor branding and QHP display changes that do not change the consumer experience. These entities add no functionality or systems to the primary EDE entity’s EDE environment that constitute part of the overall EDE end-user experience.
White-label users must conduct all aspects of the pre-application, application, and enrollment experience within the confines of a primary EDE entity’s audited and approved EDE environment. These entities face fewer audit requirements when making only minor branding changes, but they still must maintain a unique Partner ID and sign the EDE Business Agreement.
Hybrid Issuer and Non-issuer Options
Hybrid issuers are upstream EDE insurance companies that implement additional or modified functionality to a primary EDE’s technology platform and application beyond minor branding and QHP display changes. Hybrid non-issuers are upstream EDE web brokers that employ a primary EDE’s technology platform but implement additional functionality or modifications to the application that change the consumer experience.
CMS considers one key criterion in evaluating relationships between primary EDE entities and potential hybrid non-issuer upstream EDE entities: the transference of a consumer’s experience or data outside the boundaries of a primary EDE entity’s audited and approved environment. Any arrangement that sends a consumer or transmits consumer data outside the system boundaries of a primary EDE entity’s audited and approved EDE environment constitutes a hybrid non-issuer upstream EDE entity arrangement. Hybrid models need more documentation and security testing.
Audit Requirements: Business and Privacy Components
Prospective primary EDE entities face dual audit obligations before CMS approval: a Business Requirements Audit and a Privacy and Security Audit. CMS conducts both within the submission window it sets. Each audit component needs rigorous documentation, independent verification and detailed testing in multiple compliance domains.
Selecting a Qualified Independent Auditor
Each prospective primary EDE entity and prospective phase change EDE entity must hire one or more independent auditors to perform these audits and certify that the entity’s website(s) and operations comply with applicable program requirements before CMS approves the entity to use the EDE pathway. CMS treats auditors as downstream and delegated entities of the EDE entity under 45 C.F.R. § 155.221(e). The EDE entity is therefore responsible for its auditor’s performance and compliance with applicable EDE program requirements.
Auditor independence stands as a non-negotiable requirement. The auditor conducting your business requirements audit must maintain complete separation from system access or privileges to remain independent of the process. This independence will give an objective evaluation of your environment’s compliance status.
Business Requirements Audit Scope and Exhibits
The auditor conducting the business requirements audit must complete the Business Requirements Audit Report Template that CMS provides, as well as the applicable toolkits. CMS will not begin its review until the EDE entity has submitted a fully completed Business Report and applicable toolkits that include any supplemental documentation required.
The auditor must use and complete four CMS-provided toolkits: API Functional Integration Testing, Eligibility Results, Application User Interface and Communications. Each toolkit provides information such as testing scenarios and application questions that the auditor uses to verify compliance with one or more business requirement review categories.
Certain fields are designated for the auditor to complete as auditor compliance findings fields within each toolkit. The auditor must provide a conclusive and affirmative statement of the prospective EDE entity’s compliance with all requirements set forth in the review category. The auditor must assign a risk level of ‘low’ or ‘high’ to each risk identified and base the risk level determination on the severity and scope of the risk.
Privacy and Security Controls Assessment
The privacy and security audit assesses controls based on NIST 800-53 standards. Full EDE security and privacy audits assess 294 NIST 800-53 and CMS-specific controls or subsets depending on entity type. Infrastructure and operational processes must be fully implemented as evidence of ongoing monitoring and are required as part of the risk assessment and completion of the Security Audit Report.
NIST SP 800-63-3 Compliance Standards
NIST Special Publication 800-63-3 provides technical requirements for implementing digital identity services. These guidelines cover identity proofing and authentication of users who interact with government IT systems over open networks. The components of identity assurance include Identity Assurance Level (IAL) referring to the identity proofing process and Authenticator Assurance Level (AAL) referring to the authentication process. Federation Assurance Level (FAL) refers to the strength of an assertion in a federated environment.
Annual ISCM Assessment Requirements
Existing EDE entities must adhere to continuous monitoring reporting requirements in the Information Security and Privacy Continuous Monitoring Strategy Guide. This guide requires completion of an annual assessment of security and privacy controls by an auditor. A resilient compliance program and quarterly reporting are what CMS needs to stay in compliance. Monthly required scans must be provided to CMS quarterly as part of continuous monitoring requirements.
Technical Integration and API Implementation
Manual handling of EDE APIs stands as a mandatory requirement that distinguishes successful implementations. Information must flow between your application and the Exchange through a unique user interface with API integration. The EDE entity transfers information between its application and the Exchange by integrating its unique user interface with the EDE API suite.
Required EDE API Services Integration
EDE entities complete development of their environments and any related systems before starting audits. This has integrating with all required APIs. The EDE Partner Test Case Suite helps catch issues early during this integration phase. Secure tech environments with both production and testing setups become necessary. The test environment must match the EDE entity’s production setup. The audit process starts only after these integrations are complete.
Consumer and Agent/Broker Pathway Configuration
Consumer pathway requirements introduce specific account creation protocols. Consumers must now be offered the chance to create a consumer-facing account when an agent or broker helps them via the agent/broker pathway. The consumer pathway requires identity proofing before accessing the EDE environment. Consumers must create an account and be limited to creating only one account. Consumer information provided during account creation, identity proofing, and applicable sections of the eligibility application must be confirmed to arrange. A process must be implemented and available to make changes to consumer information that was verified during identity proofing.
Identity Proofing Implementation Requirements
Agent and broker pathways require distinct identity verification protocols. A process must be implemented and available to make changes to agent and broker information that was verified during identity proofing. An EDE entity-initiated change request must be submitted to CMS to get approval before implementation of manual consumer ID proofing processes. EDE entities now must implement multi-factor authentication to agents and brokers consistent with NIST SP 800-63-3.
Section 508 Compliance for UI and Communications
CMS has modified the Section 508-compliant UI and critical communication materials guidelines. This clarifies that auditors must confirm the EDE entity’s application UI and critical communications associated with the Communications Toolkit are Section 508 compliant. Section 508 web compliance means making sure your Information and Communication Technology can be used by people with disabilities and the assistive technology they use.
Documentation and Agreement Preparation
Each year before the Open Enrollment Period, CMS contacts prospective EDE entities that have submitted audits and existing EDE entities to submit applicable components of the DE Entity Documentation Package, EDE Business Agreement, and ISA for primary entities. The completeness of your submission affects approval timelines, so thorough preparation is essential.
Operational and Oversight Information Collection
The operational and oversight information form requires complete submission through a macro-enabled Excel file. This form captures critical details about your entity’s operations and oversight structure. On top of that, you must submit your entity’s corporate relationship chart showing any subsidiary, sibling, or parent company relationships. Provide this chart in Microsoft Word or PDF format. It represents corporate structure, not an organizational chart of officers and individuals.
Privacy questionnaires form another required component. Your responses may remain unchanged from your last submission. If so, you may submit an attestation on company letterhead with a signature from an officer with authority to bind the entity. Website privacy policy statements and Terms of Service must be submitted for any website collecting consumer data as part of the EDE end-user experience.
EDE Business Agreement Key Provisions
EDE entities must execute the Business Agreement to use the EDE pathway and identify selected auditors within the agreement. CMS countersigns the agreement for primary EDE entities only after reviewing and approving both the business requirements audit and annual privacy and security audit. Primary and upstream entities must submit this agreement.
ISA Appendix B: Upstream and Downstream Arrangements
Primary EDE entities must submit the Interconnection Security Agreement containing appendices that must be completed in full. Appendix B details all arrangements with upstream EDE entities, relationship types, any related data connections or exchanges, arrangements with web-brokers, and arrangements with downstream agents and brokers with proposed additional functionality or systems. The ISA must be updated and resubmitted when primary entities add or change any noted arrangements.
Required Training Completion on REGTAP
Entities must complete trainings outlined in required auditor training sections. The person taking training must complete course conclusion pages at each module’s end. Trainings are located on REGTAP at regtap.cms.gov. Entities are not required to submit training confirmation to CMS, but they must retain copies of training confirmation webpages to provide if requested.
Common Implementation Challenges and Solutions
Most entities encounter obstacles between submission and approval that extend timelines beyond original expectations. Understanding these challenges allows you to build mitigation strategies into your implementation plan.
Audit Completeness Deficiencies
CMS conducts completeness reviews on all prospective primary EDE entity and prospective phase change EDE entity audits submitted within the applicable submission window. Your opportunities to correct completeness deficiencies depends, in part, on when you submit your audit in the audit submission window. The entity must submit a complete audit, and CMS must designate the audit submission as complete before the deadline for the end of the audit submission window to advance to the next phase of review.
Environment Build Quality Issues
The approval process duration hinges on the quality of your EDE environment build. CMS’s experience with prior audits shows that prospective EDE entities submitting complete audits later in the audit submission window (mid-to-late May through June) have a lower probability of being approved to go live before the OEP. Book a Readiness Call to assess your build quality before submission.
Resubmission Cycles and Timeline Impact
Once an entity submits a complete audit, the approval process involves multiple resubmissions. The need for resubmissions may stem from compliance findings in the audit submission and resubmissions, plus issues and findings in the EDE environment and eligibility application. The number of resubmissions and back-and-forth communication depends on how quickly entities address issues and findings. The EDE approval process takes many months after an audit submission has been deemed complete and may take up to a year or more.
You Retain Control During CMS-initiated Changes
Each prospective and approved primary EDE entity must maintain a testing environment that represents the EDE entity’s EDE production environment and integration with the EDE pathway. This includes functional use of all EDE APIs. Changes deployed to the production environment must be deployed to the test environment mirroring production at the same time. This will require an EDE entity to develop a third environment to develop and test new, unapproved changes. Pursuant to 45 C.F.R. 155.221(e), the Department of Health & Human Services may suspend the EDE entity’s ability to transact information with the Exchange if HHS discovers circumstances that pose unacceptable risk.
Post-approval Oversight and Mini Audits
CMS will conduct ongoing oversight of each EDE entity in a manner consistent with that provided in previous plan years. This includes regular oversight of the entity’s EDE end-user experience in its production and testing environments. An EDE entity must not submit test data to FFE Production Environments.
Conclusion
Successful CMS EDE implementation just needs quick action and careful planning. We covered the critical April 1 to July 1, 2025 audit submission window and the complex suite of over 20 API integrations required. Different entity types have various participation models available. The transition away from Classic DE pathways by October 31, 2025 makes this move non-negotiable for web-brokers, issuers and agents serving Marketplace clients.
Development and audit processes may take a year or more. Starting now positions your organization for approval before the November 2025 Open Enrollment Period. Your readiness assessment and early submission strategy will determine whether you can serve clients during the 2026 plan year.
Key Takeaways
CMS EDE implementation for 2026 requires immediate action due to compressed timelines and complex requirements that can make or break your ability to serve Marketplace clients.
• Act now or lose market access: Classic DE pathways end October 31, 2025, making EDE mandatory for all Marketplace enrollments starting November 1, 2025.
• Submit audits early in the April-July window: Late submissions (mid-May through June) have significantly lower approval probability before Open Enrollment Period.
• Plan for 12+ month development cycles: Building and auditing EDE environments typically takes a year or more, with multiple resubmission rounds expected.
• Choose your participation model strategically: Primary entities build their own platforms with 20+ API integrations, while upstream arrangements leverage existing approved platforms faster.
• Prepare for rigorous dual audits: Business requirements and privacy/security audits must cover 294 NIST controls and comprehensive API testing before CMS approval.
The stakes are clear: entities that fail to transition to EDE before the deadline risk losing their ability to enroll Marketplace clients entirely. Early preparation and strategic model selection determine whether you’ll be ready to serve customers during the critical 2026 enrollment period.
FAQs
Q1. What is the deadline for submitting CMS EDE audit documentation for 2026 implementation? The audit submission window for prospective primary EDE entities runs from April 1, 2025, to July 1, 2025, at 3:00 AM ET. Entities must submit a complete audit that CMS designates as complete before this deadline to advance to the next phase of review. Early submission is strongly recommended, as entities submitting later in the window (mid-May through June) have a lower probability of approval before the Open Enrollment Period.
Q2. What happens to Classic Direct Enrollment pathways after October 2025? CMS will discontinue Classic Direct Enrollment, including all double redirect pathways, after October 31, 2025. Starting November 1, 2025, only Enhanced Direct Enrollment (EDE) will be permitted for Federally-facilitated Marketplace enrollments. Agencies and agents who do not transition to EDE before this deadline risk losing their ability to enroll Marketplace clients entirely.
Q3. How long does the CMS EDE approval process typically take? Developing and auditing an EDE environment may take up to or more than a year. After submitting a complete audit, the approval process typically involves multiple resubmissions and can take many months. The timeline depends on factors including the quality of the EDE environment build, the completeness of audit documentation, and how quickly issues are addressed during resubmission cycles.
Q4. What is the difference between a primary EDE entity and an upstream EDE entity? A primary EDE entity legally owns and operates the underlying technology platform, integrating with over 20 APIs and passing extensive third-party audits. An upstream EDE entity leverages a primary entity’s approved platform with customized branding or additional functionality. Primary entities must conduct full business and privacy/security audits, while upstream entities have reduced audit requirements depending on their level of customization.
Q5. What are the main audit requirements for CMS EDE approval? Prospective primary EDE entities must complete two independent audits: a Business Requirements Audit and a Privacy and Security Audit. The privacy and security audit evaluates 294 NIST 800-53 controls, while the business requirements audit uses four CMS-provided toolkits covering API functional integration testing, eligibility results, application user interface, and communications. Both audits must be conducted by qualified independent auditors and submitted within the designated submission window.