CMS's Year 9 Enhanced Direct Enrollment (EDE) auditor guidelines, dated April 10, 2026, specify an annual penetration test that includes the EDE environment and tests based on the OWASP Top 10. The guidelines govern plan years 2026 and 2027 and describe the testing, notice, auditor and submission details an EDE participant needs to put into a contract. They are program guidance tied to EDE participation and agreements, not a general penetration-testing rule for every health plan.
Quick answer. An EDE entity preparing its annual test should contract for OWASP Top 10-based testing of a lower EDE environment that mirrors production, execute Rules of Engagement with its Auditor's testing team, and notify CMS at least five business days before testing on the CMS form. The annual results go to CMS before the last business day in June after the initial audit path, according to the Year 9 guidelines, Exhibit 7. Stingrai's human-led web application and API penetration testing can be considered as a testing component through the Auditor's team or a disclosed Auditor subcontracting arrangement, with the EDE entity and Auditor agreeing on the reporting and submission handoff.
This guide is for a security lead, EDE program owner or procurement team at an approved or prospective Qualified Health Plan issuer, web-broker or relevant technology provider. It translates the CMS text into a statement of work (SOW) and evidence request. The full CMS EDE resource page remains the place to check the latest program materials and approved-entity list before procurement. CMS says its guidelines do not independently have the force of law unless incorporated into a contract, so check the current EDE Business Agreement, Interconnection Security Agreement (ISA) and instructions issued to your entity.
Figure 1: The three CMS policy sources a buyer must keep distinct. Sources: CMS EDE Year 9 guidelines, CMS ARC-AMPE Volume I, CMS-0057-F fact sheet.
Who needs this test and which CMS obligation applies?
EDE lets approved issuers and web-brokers host an Exchange eligibility and enrollment experience on their own websites, integrated with Marketplace APIs. CMS says the pathway applies to the Federally-facilitated Exchange (FFE) and State-based Exchanges on the Federal Platform (SBE-FPs). It does not extend the EDE program to a state exchange using its own platform or to a Medicare Advantage portal simply because both are health insurance technology. The CMS EDE landing page distinguishes primary entities, which build the platform, from upstream entities, which use a primary entity's platform.
That distinction changes who contracts for testing and how the work reaches CMS. The Year 9 guidelines give prospective primary entities an initial operational readiness review (ORR). They also identify prospective hybrid issuer upstream and hybrid non-issuer upstream entities in the Annual Penetration Testing row of Exhibit 7. Existing primary entities and specified hybrid upstream entities follow the Information Security and Privacy Continuous Monitoring (ISCM) process, including an annual controls assessment by an Auditor. A white-label upstream user with no added functionality should not assume that it must commission a duplicate full-platform audit; first determine its role and the primary entity's boundary from its agreements and CMS guidance.
Your position | Procurement question | Source of the answer |
|---|---|---|
Prospective primary EDE entity | Is this the initial ORR, with the penetration test results submitted alongside the Security Assessment Report (SAR)? | |
Existing approved primary EDE entity | Which ISCM reporting package and annual test window apply under your current agreements? | |
Hybrid issuer or non-issuer upstream entity | What did your added single sign-on, functionality or system change put inside your own assessed boundary? | |
White-label upstream user | Which controls and evidence are inherited from the primary entity, and which obligations remain under your agreement? |
EDE, ARC-AMPE and CMS-0057-F are distinct
The Year 9 EDE guidelines contain the direct annual EDE test instructions in Exhibit 7. ARC-AMPE Volume I is CMS's broader security and privacy framework for ACA administering entities and selected partner entities. It classifies EDE roles and sets mandatory versus non-mandatory implementation by entity type. Its controls and continuous monitoring artifacts can feed an EDE privacy and security audit, but the EDE test row is the most precise procurement source for the EDE environment, notice and testing location.
CMS-0057-F concerns FHIR API development and enhancement by named impacted payers, including Medicare Advantage organizations, Medicaid and CHIP programs or plans, and FFE QHP issuers. Its API deadlines generally begin in 2027, with exact dates varying by payer type. The CMS-0057-F fact sheet does not set this EDE annual penetration test. An FFE issuer may have both sets of work, but a prior authorization API test under CMS-0057-F is not automatically a test of its EDE eligibility and enrollment environment. Scope each under the correct system boundary and evidence owner. For the payer API side, see our CMS-0057-F API scope guide.
The exact EDE testing instruction buyers should put in the SOW
Exhibit 7 of the Year 9 guidelines supplies the minimum acceptance points. The penetration test includes the EDE environment and tests based on the OWASP Top 10. Before testing, the EDE entity executes Rules of Engagement with its Auditor's penetration testing team. The EDE entity also gives its CMS designated technical counterparts the schedule and a CMS form at least five business days before initiation. The form lists the test period, target IP addresses, hostnames and URLs, plus restricted hosts, systems or subnets.
The same row prohibits testing in production and targeting IP addresses used for the CMS and non-CMS organization connection. The test is performed in a lower environment mirroring production. This is operationally important: a proposal that says only “test the public EDE website” can leave out authenticated flows, hosted integrations and the lower-environment boundary. Equally, a default external production test conflicts with CMS's EDE test instruction even when production is the easiest URL for a tester to reach.
Figure 2: Required test preparation and result handoffs in the Year 9 EDE guidelines. Source: CMS, Year 9 EDE auditor guidelines, Exhibit 7.
Minimum terms to put in writing
System boundary: identify the primary EDE platform, the entity's added upstream components where applicable, user-facing eligibility and enrollment flows, and each interface that collects personally identifiable information (PII) or connects to CMS. CMS says the privacy and security Auditor must be capable of penetration testing and vulnerability scans on those interfaces. The SOW should name every target and every excluded asset, rather than use “all related systems.”
Environment: name the lower environment, its URLs and IP ranges, who controls it, and how its code, configurations, EDE APIs, roles and end-user experience reflect the approved production environment. The Year 9 guidelines require an approved primary entity to maintain a test environment that accurately represents production, including functional use of all EDE APIs. Document any permitted difference so the report can say what was and was not exercised.
Test method: require authenticated web and API testing based on the OWASP Top 10, with explicit coverage of roles, authorization boundaries, session handling, input validation and business logic. These are sensible SOW details for the EDE environment, not additional CMS test categories. Ask the tester to state which Top 10 categories were applicable, how they were tested and where a category was not applicable.
Rules of Engagement: make the signed agreement between the EDE entity and the Auditor's testing team a start condition. Include contacts, test windows, approved accounts, safe handling of test data, notification and stop rules, and the production and CMS connection exclusions. The quote should reserve time to finalize the document before any test traffic.
CMS notification: name the EDE employee responsible for the CMS form and technical-counterpart notice. Require the testing team to provide the precise period, target resources and restrictions early enough for the entity to meet the five-business-day minimum. Save evidence of the completed notice and receipt with the engagement record.
Outputs: require an environment-specific report with methodology, targets, dates, findings, severity rationale, reproducible evidence that is safe to share, remediation guidance and explicit limitations. Define who prepares a retest record and who maps open findings into the SAR or POA&M where those artifacts apply. The initial audit's test results go with the SAR through CMS's designated file-sharing system, according to Exhibit 7.
The SOW should say whether the testing firm is the contracted privacy and security Auditor's own team or a subcontractor engaged through that Auditor. CMS permits Auditor subcontracting but requires the arrangement and potential conflicts to be disclosed. Mere coordination with a separately retained specialist is not the Auditor-team arrangement described in Exhibit 7. The EDE entity must have a written agreement with each independent Auditor and submit the relevant agreement to CMS. Avoid language that treats a penetration test supplier as the full ORR Auditor just because it can produce a strong technical report. The selection and independence provisions in section VI cover the Auditor's capabilities, conflicts and objectivity across the audit.
Build a test environment that can carry the evidence
Testing a lower environment is a requirement, not a reason to test a simplified demo. The Year 9 guidelines say the representative test environment must reflect the EDE end-user experience and the functional use of EDE APIs. Changes deployed to production must be deployed concurrently to that mirrored environment. For procurement, the practical question is whether a tester can exercise the same trust boundaries without touching real enrollment transactions or the prohibited CMS connection addresses.
Before issuing the purchase order, ask the platform owner for an environment inventory. It should connect each approved production component to its lower-environment counterpart, then list test identities for consumer, agent or broker, administrator and support roles that exist in the implementation. Include test data handling rules, API routing and any mock or stubbed external service. A stub can be necessary for safe testing; its limitation should appear in the final report because it may remove a trust boundary from scope. Have the platform owner confirm that the testing windows, account permissions and network allowlists are ready before the five-business-day CMS notice is sent.
A useful test plan follows an EDE transaction across authentication, eligibility application, document upload, enrollment and subsequent changes only where those features exist in the entity's approved implementation. For each flow, ask how the test verifies that one user or role cannot read, alter or submit another person's information, that the server enforces permissions, and that a session cannot be reused in a way the application did not intend. This is buyer guidance drawn from the web application risk model, not an extra CMS checklist. Document which workflows were unavailable in the lower environment so the Auditor can decide whether the evidence is complete.
CMS's production restriction should be explicit in the test plan, firewall allowlist and testers' target manifest. A link to the live site in a ticket or a copied production URL is not an authorization to test it. Record a named person who can pause testing if traffic reaches an unintended host. For an upstream entity, agree in writing which primary-platform endpoints the tester may touch and which inherited controls the primary entity will evidence. A test of a branded landing page alone does not demonstrate the security of newly added upstream functionality.
Evidence that should survive CMS review and remediation
The penetration test report matters because the EDE program uses it inside a larger assessment and continuous monitoring record. Exhibit 7 calls for prospective EDE entities and their Auditors to submit test results with the SAR through the CMS designated file-sharing system. For ongoing participation, the same row says EDE entities perform testing and submit results annually before the last business day in June, consistent with ISCM. In the initial privacy and security audit, CMS expects the SAR to summarize all findings from documentation review, control testing, scanning, penetration testing and interviews. Its complete-submission criteria in Exhibit 10 call for open SAR findings to appear in the Plan of Action and Milestones (POA&M).
Give the Auditor and entity owner a handoff package with these items:
Authority and scope: the signed contract and test SOW, Auditor or subcontractor relationship, independence documentation where the Auditor needs it, target inventory and signed Rules of Engagement.
Timing: the CMS notification form, evidence it was sent at least five business days before testing, the approved test window and a dated test log.
Environment fidelity: a short mapping from production components and roles to the lower environment, with exclusions, stubs and material differences recorded.
Technical results: a report that identifies the OWASP Top 10-based methodology, tested URLs and interfaces, account roles, finding evidence, severity rationale and unresolved limitations. Ask for an executive summary and a finding-level appendix with enough detail for engineers to reproduce fixes without including live consumer data.
Remediation trail: a stable finding identifier, owner, due date, fix decision, retest result and the cross-reference that lets the Auditor place open items in the SAR and POA&M. Keep the original result and the retest record as separate dated evidence.
Submission handoff: the final file names, versions and responsible uploader for CMS's designated file-sharing system. CMS says the platform it currently uses can change, so rely on the instructions given to the entity for that cycle.
Do not confuse the annual test with the monthly vulnerability scans listed separately for prospective entities in Exhibit 7. A scan inventory and a penetration test answer different questions and have different artifact paths. The tester's report should tell the Auditor which findings came from active testing and which came from a scan, while the entity maintains the applicable POA&M record.
Calendar for an approved entity versus a new applicant
For an existing entity preparing the recurring test, plan backward from the annual CMS result submission specified as prior to the last business day in June in Exhibit 7. Leave time for environment preparation, independent tester onboarding, the signed Rules of Engagement, the minimum five-business-day CMS notice, test execution, remediation, retesting and Auditor review. The guidelines do not prescribe a universal number of testing days or a vendor lead time; put those dates in the SOW based on your environment and Auditor's deliverable schedule.
For a prospective primary EDE entity, the initial Year 9 audit window ran from April 1, 2026 to July 1, 2026 at 3:00 a.m. Eastern Time. That window had already closed by this article's October 2026 publication date. CMS says it will release guidance for a future annual submission window, so do not reuse the Year 9 initial dates as a 2027 application deadline. The initial audit also has earlier planning gates: the Auditor prepares a Security and Privacy Controls Assessment Test Plan (SAP) for CMS review at least 30 days before the assessment, and the entity gives DE Support at least 30 days' notice before the Auditor begins the audits. These are initial audit planning requirements, not substitutes for the separate five-business-day penetration-testing notice. Check CMS's current EDE resources and your CMS contact before fixing the procurement calendar.
Compare proposals on scope, evidence and ownership
A low bid is not comparable to a full EDE test if it assumes production access, omits the Auditor handoff or counts a scan as the annual penetration test. Ask each bidder to respond to the same fields. If the Auditor subcontracts the technical test, specify that relationship and the Auditor's submission responsibilities in the contract.
Proposal field | Ask the bidder to specify | Why the buyer needs it |
|---|---|---|
Team and independence | Named testers, relevant web/API testing experience, relationship to the EDE entity and Auditor, subcontracting and conflict disclosures | CMS's section VI addresses independent Auditors and disclosed subcontractors. |
Tested boundary | Lower-environment hosts, applications, APIs, user roles and excluded CMS connection resources | Exhibit 7 specifies what must be included and what must not be targeted. |
Method | How the OWASP Top 10 informs authenticated EDE testing and how limitations are recorded | A bare “OWASP compliant” label does not explain what the tester actually did. |
Start conditions | Signed Rules of Engagement, working accounts, lower-environment readiness and CMS notification owner | CMS requires the agreement and minimum notice before testing. |
Deliverables | Findings report, evidence, retest record, SAR/POA&M mapping and secure handoff format | The Auditor and entity need results they can use in the CMS process. |
Commercial terms | Fixed test scope, change-order triggers, included retest, additional-role or endpoint rates, and quote currency | It makes proposals comparable when the environment differs from a standard web application. |
There is no CMS-published EDE penetration-test price in the Year 9 guidelines. Ask for a custom quote based on the actual EDE boundary, number of roles and endpoints, lower-environment readiness, reporting, retesting and Auditor coordination. An EDE platform that includes more than one application or separately assessed upstream components needs a written scope, not an assumed package price. In Canada and the United States, tell bidders whether you need the quote in C$ or US$ and whether taxes, travel or subcontractor fees are included. Use our broader web application penetration testing scope and cost guide to compare testing approaches without importing its generic scope into the CMS submission.
Where Stingrai fits
Stingrai is a Toronto-headquartered, CREST-accredited penetration testing company. Its human-led web and API engagements can be scoped for authenticated roles, authorization, business logic, session handling and the OWASP Top 10, with reporting and retesting. For an EDE buyer, a technical specialist's work should sit within the independent privacy and security Auditor's team or disclosed subcontracting arrangement. The entity and Auditor should confirm the tester's role, independence, lower-environment boundary and submission format before testing begins.
Stingrai supports one-time annual engagements and continuous testing programs. The EDE annual submission needs a dated, bounded test even if a team also uses continuous testing between cycles. An EDE platform or multi-entity arrangement is scoped by quote; book a discovery call to map the tested environment, roles, Auditor handoff and result deadline before procurement. Stingrai's testing produces evidence for the EDE privacy and security review and helps the entity remediate findings.
Frequently Asked Questions
Does CMS require an annual penetration test for Enhanced Direct Enrollment?
Yes. CMS's April 2026 Year 9 EDE guidelines say the annual test must include the EDE environment and OWASP Top 10-based tests. After initial approval, EDE entities perform testing and submit results to CMS annually before the last business day in June, consistent with ISCM. The exact entity and evidence path depends on whether the entity is primary, hybrid upstream or an upstream user of another platform.
Does the EDE penetration test have to run in production?
No. The Year 9 guidelines direct the Auditor's team to test a lower environment that mirrors production. They prohibit penetration testing in production and targeting IP addresses used for the CMS and non-CMS organization connection.
How much notice must the EDE entity give CMS before testing?
At least five business days before penetration testing starts, the EDE entity must notify its CMS designated technical counterparts using the CMS-provided form. It supplies the testing period, target IP addresses, hostnames and URLs, and restricted hosts, systems or subnets.
Who signs the EDE penetration testing Rules of Engagement?
The EDE entity executes Rules of Engagement with its Auditor's penetration testing team before testing. The SOW should identify the signers, the exact lower-environment targets and the person who can stop a test that reaches an unintended system.
Can a separate penetration testing firm work with the EDE Auditor?
Yes, as part of the Auditor's testing team through a disclosed Auditor subcontracting arrangement. The Year 9 guidelines permit an Auditor to subcontract, require disclosure of the subcontracting arrangement and potential conflicts, and assign the EDE entity responsibility for its Auditor's work. Coordination alone is not the Auditor-team relationship specified in Exhibit 7. Confirm in the contract who owns the SAR, CMS submission and retest handoff.
When are annual EDE penetration test results due?
For ongoing EDE participation, Exhibit 7 of the Year 9 guidelines says results go to CMS annually prior to the last business day in June, consistent with ISCM. A prospective primary entity follows its initial audit submission window instead; CMS's 2026 initial window closed on July 1, 2026 at 3:00 a.m. Eastern Time.
Does CMS-0057-F create the EDE annual penetration test requirement?
No. CMS-0057-F addresses FHIR API requirements for defined impacted payers, with API compliance dates generally beginning in 2027. The EDE annual testing instruction comes from the separate CMS Year 9 EDE guidelines and EDE participation framework. An organization subject to both should scope and evidence each system boundary separately.
Is a monthly vulnerability scan enough for the EDE annual test?
No. Exhibit 7 lists annual penetration testing and monthly vulnerability scans as separate evidence items for prospective entities. The annual penetration test must include the EDE environment and OWASP Top 10-based tests; a scan alone does not demonstrate that work.
What should an EDE buyer ask a tester to deliver?
Ask for a signed Rules of Engagement, a dated target and exclusion list, lower-environment fidelity notes, a report mapping tested EDE flows to the OWASP Top 10, finding evidence and remediation guidance, and a retest record. Confirm that the Auditor can incorporate the results into the SAR and POA&M where those artifacts apply, and that the entity can submit the annual results through CMS's designated system.
Related reading
References
CMS. Third-party Auditor Operational Readiness Reviews for the Enhanced Direct Enrollment Pathway and Related Oversight Requirements, Year 9, April 10, 2026. https://www.cms.gov/files/document/guidelines-enhanced-direct-enrollment-audits-year-9-final.pdf. Sections IV, VI, VIII and XI, and Exhibit 7 are the operative sections cited here.
CMS. Enhanced Direct Enrollment, read October 23, 2026. https://www.cms.gov/marketplace-private-insurance/agents-brokers/direct-enrollment-partners. Program scope, primary and upstream roles, and current guidance links.
CMS. ARC-AMPE Volume I, version 1.02, April 10, 2025. https://www.cms.gov/files/document/arc-ampe-vol-1-v102-508-5cr-04112025.pdf. Entity categories and applicability tables.
CMS. CMS Interoperability and Prior Authorization Final Rule CMS-0057-F, January 17, 2024. https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-prior-authorization-final-rule-cms-0057-f. Impacted payer and API scope.
Talk to Stingrai
Get a lower-environment web and API test scoped around your EDE boundary, the Auditor handoff and the CMS evidence deadline. Get a Quote or book a free discovery call.
