The Global Status of eCTD 4.0 in Mid-2026

eCTD 4.0 has been on the horizon for a decade. The ICH Assembly endorsed the Step 4 Implementation Package back in December 2015, and the Implementation Guide has since moved through multiple versions, with v1.6 and Controlled Vocabulary Package v1.0.2 endorsed by the Assembly in May 20241. What has changed in the last twenty-four months is that agency readiness has finally caught up with the specification. A sponsor planning submissions in 2026 and 2027 now has to think about v4.0 in every major region.

Japan’s PMDA leads the pack. Following a 2021 technical pilot and voluntary acceptance starting in 2022, PMDA now mandates eCTD v4.0 for new applications as of April 1, 20262. Sponsors filing into Japan can no longer use v3.2.2 for new applications, which makes Japan the first major regulator to force the decision.

April 2026 PMDA Japan mandate takes effect for new applications
Sept 2024 FDA began accepting eCTD v4.0 for NDA, BLA, ANDA, IND, MF
Dec 2025 EMA optional acceptance began for new centrally authorised MAAs

The US FDA opened acceptance of eCTD v4.0 for CDER and CBER submissions on September 16, 2024, covering new NDAs, BLAs, ANDAs, INDs, and Master Files3. FDA’s public position remains that use is optional through the current window, with mandatory adoption still targeted for later in the decade. Importantly, FDA is currently focused on new applications; the “forward compatibility” capability that will let a sponsor switch an in-flight v3.2.2 lifecycle to v4.0 is being built out through 20264.

The EMA went live with optional use of eCTD v4.0 for new centrally authorised product marketing authorisation applications on December 22, 2025, with a Pilot Phase 3 for forward compatibility opening in early 20265. EMA has telegraphed that a refreshed set of EU eCTD validation criteria becomes applicable on July 15, 2026, aligning the validator behaviour with the dual-version reality of v3.2.2 and v4.0 running in parallel. EMA has publicly targeted 2027 for mandatory v4.0 use for CAPs, with the precise compliance date to be confirmed during 2026.

Health Canada and Swissmedic are further behind but visibly moving. Health Canada published a draft Canadian Module 1 v4.0 Implementation Guide back in 2019 and industry commentary now expects optional acceptance to begin during 2026 with mandatory use around 20286. Swissmedic has published a draft implementation guide and has signalled a technical pilot with voluntary submissions in eCTD 4.0 format, targeting mandatory use around 20287. The other ICH regions, including the TGA in Australia and various Asian agencies, are following ICH M8 with their own regional Module 1 packages.

The uneven pace matters more than the average pace.

Your program cannot wait for the slowest agency in your portfolio. If you file in Japan, PMDA has already made the decision for you. If you file in the EU, the 2027 mandate is close enough that anything more than a modest pilot in 2026 is late. And if you file in the US, the strategic question is not whether to adopt but whether to lead or lag your product portfolio.

What Actually Changes in the v4.0 Content Model

eCTD 3.2.2 was a folder-and-XML backbone: an index.xml file described a directory tree of PDFs, and lifecycle operations were expressed through a small vocabulary (new, replace, append, delete) applied to leaf nodes. It worked, but it was tightly coupled to file locations and offered no rich way to describe reuse, grouped documents, or complex lifecycle events across sequences.

eCTD 4.0 is architecturally different. It is built on the HL7 Regulatory Product Submissions (RPS) Release 2 standard, itself based on the HL7 Version 3 Reference Information Model8. Instead of a folder tree, a v4.0 submission is a structured XML message that describes documents, their relationships, and how they should be presented to the reviewer.

Keywords replace folder position as the semantic anchor

The single biggest conceptual change is the shift from “position in the CTD hierarchy” to “keywords describing the document.” In v4.0, an object called contextOfUse attaches a document to one or more keywords. Keywords come from controlled vocabularies specified by ICH, by regional authorities, by HL7, by external organisations, and by the sender themselves9. A single document can be attached to multiple contexts of use, which is how v4.0 delivers document reuse.

Lifecycle operations become richer

v4.0 introduces the ability to replace many documents with one, or one document with many. Because lifecycle is tracked via the contextOfUse element (rather than at the file level), sponsors can restructure content across sequences in ways that v3.2.2 simply could not represent. A priority number is used to preserve the intended order of contextOfUse elements that share the same set of keywords9.

Controlled vocabularies become critical infrastructure

Because keywords carry the semantic weight of the submission, the controlled vocabulary (CV) packages become production infrastructure rather than reference material. Sponsors must be able to consume updated CV packages from ICH and regional authorities, apply them to submissions, and validate against them. The v4.0 CV Package is now versioned separately from the Implementation Guide precisely to allow this to happen on a faster cadence1.

v3.2.2

Folder + index.xml

Documents live in a directory tree. Lifecycle operations (new, replace, append, delete) are applied to file-level nodes. Reuse means duplicating files across sequences.

v4.0

RPS message + keywords

Documents are described in an XML message with contextOfUse elements and keyword sets. Same document can appear in multiple contexts. Lifecycle handles one-to-many and many-to-one replacement.

v3.2.2

Regional Module 1 folder

Region-specific structure baked into folder layout. Cover letters, forms, and administrative content organized by folder convention.

v4.0

Regional keywords + CV

Module 1 content described by regional keywords and controlled vocabularies. Each region (FDA, EMA, PMDA, HC, Swissmedic) publishes its own Regional Module 1 Implementation Guide.

v3.2.2

Study tagging file

Datasets referenced through the STF (Study Tagging File), a separate XML layer describing study-level content.

v4.0

Native document/dataset objects

Datasets are first-class objects in the RPS message. Reduces the tooling gap between clinical data submission and eCTD publishing.

Why “content reuse” matters commercially

The reuse pattern is not an abstract benefit. A sponsor filing the same CMC content into three different regions today has to duplicate PDFs across three eCTD sequences and manage three lifecycles for what is effectively one document. In v4.0, that same document can be attached to three contexts of use with three sets of regional keywords. Publisher burden drops, and, importantly, so does the risk of downstream discrepancies between what one agency and another believes is the current version10. This is where most of the operational value of v4.0 actually lives.

The commercial implication is that the payback on a v4.0 investment is not really the submission itself. It is the effect on downstream operations: labeling change coordination, CMC variation management, safety updates, and annual report cycles all become simpler when a single source of truth carries through to every region. Sponsors who model the business case only on publishing productivity per submission understate the return by a wide margin.

A Realistic 18 to 24 Month Migration Timeline

Vendors and industry commentators have converged on 18 to 24 months as a realistic window for a mid-sized sponsor moving from full v3.2.2 operations to production-ready v4.0 capability across multiple regions. Companies with heavy legacy backlogs, complex product portfolios, or unusual outsourcing arrangements can push toward the longer end. What follows is a template that a program manager can adapt.

1

Months 0-3: Scoping and Baseline

Establish the program charter, stakeholders, and decision rights. Inventory in-flight submissions by region, product, and application type. Inventory current tooling (publishing, RIM, DMS, gateway). Map the ICH M8 v1.6 Implementation Guide and each relevant Regional Module 1 IG against your current SOPs. Set the target regions and dates that anchor the program.

2

Months 3-6: Vendor Alignment and Architecture

Confirm publishing vendor roadmap and target release. Confirm RIM system readiness (Veeva RIM, Ennov RIM, ArisGlobal LifeSphere, and others). Design the integration architecture: content management to publishing to gateway. Decide whether to run parallel v3/v4 environments or a single dual-capable environment. Sign vendor contracts and license schedules.

3

Months 6-9: Configuration and Controlled Vocabularies

Install and configure the v4.0-capable publishing environment. Load ICH CV Package v1.0.2 and current regional CV packages. Configure regional Module 1 templates. Build sender-defined keyword strategy. Reconfigure document metadata in the DMS/RIM to carry the keywords and controlled vocabulary values v4.0 needs.

4

Months 9-12: Sample Submissions and Pilot

Prepare and submit sample eCTD v4.0 packages to FDA via the optional sample submission process. Participate in EMA forward compatibility pilots if in scope. Run internal end-to-end pilots covering INDs/CTAs, variations, and annual reports. Use dry runs to force out issues in metadata, keywords, hyperlinking, and validation.

5

Months 12-15: SOP Rewrites and Training

Rewrite regulatory operations SOPs for v4.0 workflows. Update authoring guidance for medical writing and CMC teams. Train publishing team, RA operations, and reviewers on the new content model. Address the FHIR/HL7 knowledge gap that most XML-native ops teams will hit.

6

Months 15-18: Production Cutover

Move first live submissions to v4.0 in the region furthest along (typically Japan first, then FDA new applications). Retain v3.2.2 capability for legacy sequences in regions still in transition. Monitor validation outcomes and agency feedback closely. Establish weekly cutover forums to run down issues fast.

7

Months 18-24: Portfolio Migration and Optimization

As forward compatibility becomes available in FDA and EMA, migrate priority legacy lifecycles to v4.0. Retire dual-track SOPs and consolidate on a v4.0-first operating model. Measure realized benefits: cycle time, reuse rates, agency queries, publishing effort per sequence. Feed learnings into the next round of vendor and process improvements.

Where sponsors compress the timeline safely. Two phases genuinely compress with discipline: vendor alignment (months 3-6) accelerates if you have an existing strategic vendor relationship and can bypass long procurement cycles, and pilots (months 9-12) accelerate if you already have an in-flight submission that would fit the FDA sample process. Everything else has real dependencies that resist compression and reappear as risk later if you ignore them.

The Dependency Map No One Draws Until It Is Too Late

Most eCTD 4.0 programs run into trouble because the leadership team never draws the dependency map explicitly. The migration is a graph, not a checklist, and the ordering of decisions matters. Below is the map we walk clients through.

DependencyDepends onEnablesTypical failure if ignored
Regional Module 1 IG version FDA, EMA, PMDA, HC, Swissmedic release cadence Publishing template configuration Template built against wrong IG; rework at pilot stage
Controlled Vocabulary Package version ICH and regional CV maintenance Keyword strategy and validation Validation failures at agency; missed CV updates in production
Publishing vendor upgrade path Vendor product roadmap; contract renewal All downstream configuration and pilots Late-stage discovery that vendor is not ready; program stall
RIM system readiness Vendor upgrade path; RIM data model Content metadata for keywords Manual metadata entry per submission; publishing throughput drops
Document management metadata RIM readiness; document authoring workflows Reuse across regions Documents cannot be reused; publisher recreates them per region
Gateway / EDT capability Agency gateway readiness (FDA ESG, EMA gateway, PMDA) Production submission of v4.0 messages Ready to publish but not ready to transmit; last-mile blocker
Sample / pilot submissions Publishing config; agency sample program; in-flight application Real-world validation feedback before production First production submission is also first learning cycle
SOPs and training Vendor configuration; regional playbooks Repeatable operations after go-live Cutover succeeds; the sixth submission fails because staff never learned
Forward compatibility use Agency FC readiness (FDA fall 2026, EMA mid-2026 pilots) Migration of legacy lifecycles Sponsor stuck with dual-track ops longer than planned

The dependency map is not just a project management artefact. It is the tool leadership uses to answer questions that will come up more than once: “Can we still hit our Japan mandate if the RIM upgrade slips?” “Which region should we pilot first?” “What happens if the vendor pushes their v4.0 GA date back a quarter?” Without the map, those questions get answered with instinct instead of analysis.

A pragmatic rule for sequencing. Start from the leaf you cannot control (agency mandate dates), work back through the leaves you partly control (agency pilots, sample programs, vendor GA), and only then make decisions about the leaves you fully control (SOPs, training, cutover date). Programs that invert this order almost always end up rebuilding downstream work.

Publishing Vendor and Tooling Decisions

The publishing tooling market has consolidated around a small number of vendors capable of delivering full v4.0 support: Veeva Vault Submissions, Lorenz docuBridge, EXTEDO EURS (and eCTDmanager), Ennov, Parexel, and a handful of smaller specialists11. Veeva announced in late 2024 that Vault RIM would support eCTD 4.0, and other major vendors have publicly signalled parallel investments.

Questions to put to any publishing vendor

  • Which ICH IG version does your product currently support, and what is your commitment to keeping current? A vendor that supports v1.5 today needs to have a credible plan for v1.6 and beyond.
  • Which regional Module 1 IGs are in production, in beta, and on the roadmap? FDA M1 IG v1.7 is the current baseline for US submissions; EMA and PMDA have their own release cadences.
  • How is the Controlled Vocabulary Package managed? A vendor that requires a services engagement to update CVs is a red flag. CV updates should be routine and automated.
  • What is your forward compatibility story? Sponsors will need to switch existing v3.2.2 lifecycles to v4.0 as agencies enable FC. The vendor’s approach to lifecycle migration is worth pressure testing.
  • How do you validate against ICH and regional validation criteria? Sponsors need pre-submission validation that mirrors what the agency validator will apply.
  • What does your gateway connectivity look like? FDA ESG (AS2, USP, API), EMA gateway, PMDA connectivity, and Health Canada CESG each have specific requirements.
  • Where does the tool sit in your RIM ecosystem? If you are on Vault RIM, native Vault Submissions is the shortest path. If you have Lorenz docuBridge next to a non-Veeva RIM, the integration architecture matters more.

The FHIR knowledge gap is real. eCTD v4.0 replaces the v3.2.2 XML backbone with an HL7-based structure. Most regulatory operations staff have XML experience but limited HL7/FHIR experience12. When evaluating vendors, look hard at what they abstract away for the publisher versus what they expose. Sponsors have been surprised to discover that a “user-friendly” v4.0 tool still requires the operator to reason about keyword hierarchies and contextOfUse ordering.

Build, buy, or extend?

A small minority of sponsors have historically maintained custom publishing tooling. For v4.0, “build” is essentially off the table for anyone without a dedicated regulatory technology team. The specification is complex, the CV maintenance burden is real, and agency validation criteria change often enough that an internal team spends most of its time chasing releases. For almost every sponsor, the decision is between staying with an existing vendor (and ensuring their roadmap aligns) or switching (which adds data migration risk).

Sponsors on Veeva Vault RIM have a shorter integration path to Vault Submissions than to a third-party publisher, because content management, RIM, and publishing sit under a common data model. Sponsors on Lorenz docuBridge or EXTEDO eCTDmanager with a non-Vault RIM have to weigh integration effort against the maturity of the incumbent’s v4.0 roadmap. A structured evaluation typically compares four dimensions: v4.0 feature completeness, CV maintenance model, gateway coverage, and total cost of ownership across the current v3.2.2 legacy and the future v4.0 volume.

When switching vendors is the right call. Vendor switches during a v4.0 program can pay off when (a) the incumbent has a weak v4.0 roadmap; (b) the RIM/publishing integration has been a chronic pain point; and (c) the sponsor has enough in-flight submission volume to justify the migration effort. Sponsors switching purely because “v4.0 is a good moment to reconsider” usually regret the added scope. Reserve the switch for cases where the incumbent is genuinely blocking.

Regional Playbooks: FDA, EMA, PMDA, Health Canada, Swissmedic

Each region has its own regulatory pace, technical guidance, and gateway posture. The migration playbook needs region-specific chapters, not a single blended timeline.

United States: FDA

FDA acceptance of eCTD v4.0 for new applications went live on September 16, 2024, covering NDA, BLA, ANDA, IND, and Master File submissions to CDER and CBER13. FDA also runs an optional sample submission program, in which sponsors submit a test v4.0 package for technical feedback (sponsors must have an application number and plan to file an actual submission within twelve months of the sample request)14. Six companies submitted test submissions during the completed pilot; eleven companies participated overall.

The FDA’s approach is deliberate. Forward compatibility (the ability to switch an in-flight v3.2.2 lifecycle to v4.0) is targeted for fall 2026. The current FDA Module 1 v4.0 Implementation Guide is v1.7. Sponsors filing into the US should be piloting samples in 2026 and cutting over new applications by 2027, so that by the time FDA moves to mandatory use later in the decade the sponsor’s operations are unremarkable, not exceptional.

European Union: EMA

The EMA went live with optional acceptance of eCTD v4.0 for new centrally authorised MAAs on December 22, 202515. In early 2026 EMA opened Pilot Phase 3 on Forward Compatibility for CAPs (starting with the simplest cases and progressing to grouped submissions), and refreshed EU eCTD validation criteria become applicable on July 15, 2026. EMA has publicly targeted 2027 as the year of mandatory v4.0 for CAPs, with the exact date to be confirmed during 2026.

For sponsors, the practical implication is that EMA’s parallel path (v3.2.2 and v4.0 both accepted) is a real transitional window, not an indefinite one. If you plan a new CAP MAA in 2026 or 2027, you should have a definite view on which format you will use, and your rationale should be written down.

Japan: PMDA

PMDA is the pace-setter globally. Voluntary acceptance began in 2022, and mandatory adoption for new applications took effect on April 1, 2026. PMDA no longer accepts v3.2.2 for new applications16. Sponsors with an active Japanese portfolio have already made the decision; sponsors planning first-time Japanese filings have to plan v4.0 from day one.

Canada: Health Canada

Health Canada’s Draft Canadian Module 1 v4.0 Implementation Guide was published in 2019, and industry expectation is that optional acceptance will begin in 2026, with mandatory use around 2028. Health Canada uses its Common Electronic Submission Gateway (CESG) for transmission. Because Health Canada often follows other regions closely, sponsors targeting Canadian filings can generally rely on their FDA-focused work to be reusable, with regional Module 1 differences configured on top.

Switzerland: Swissmedic

Swissmedic has published a draft eCTD v4.0 implementation guide and is running a technical pilot with voluntary submissions in 4.0 format, targeting mandatory use around 2028. The Swiss regulatory environment tends to align closely with EMA’s technical decisions, so sponsors already piloting with EMA will find much of the work transferable.

SD perspective on regional sequencing. The order most global sponsors should follow is: Japan first (because the mandate is behind them), FDA new applications second (because sample submissions are easy to arrange and feedback is useful), EMA CAP MAAs third (because the 2027 mandate is real), then Health Canada and Swissmedic tucked in as their optional windows open. Sponsors doing this in the opposite order (EMA first because the EU is the biggest market) often burn cycles building capability that has to be reworked once the more mature FDA and PMDA specifications become the baseline.

Common Migration Risks and How to Neutralize Them

The risks in an eCTD 4.0 migration are predictable. They come from vendor dependencies, content model complexity, agency uncertainty, staff readiness, and the mechanics of running two submission formats side by side. What follows is a short catalogue with concrete mitigations that boutique consultants and regulatory ops leaders keep in their back pockets.

Risk: Vendor roadmap slippage

Vendors publish confident roadmaps. Roadmaps slip. The mitigation is not to distrust vendors but to build the program timeline with milestone dates that give you ninety days of cushion between vendor GA and your first pilot. Ask the vendor for reference customers already in production with the target release, not just customers in beta.

Risk: FHIR / HL7 knowledge gap in the operations team

Publishing staff who have been fluent in v3.2.2 XML for a decade will not automatically pick up the RPS message model. Budget for real training (not a one-hour recorded webinar), and consider having a subject matter expert embedded during the first two production submissions in each region.

Risk: Content metadata not ready for keywords

Documents in your DMS today were tagged for a folder-based world. If your metadata does not carry the information needed to derive v4.0 keywords, either publisher productivity drops or your reuse benefits never materialize. Fix metadata during migration, not after.

Risk: Controlled vocabulary drift

CV packages update on their own cadence. If your publishing tool cannot easily consume updates, you will silently fall behind and validation failures will start appearing at the agency. Verify with the vendor that CV updates are a routine operation, and assign an owner internally.

Risk: Dual-track operations become permanent

Running v3.2.2 and v4.0 in parallel is expensive. Every SOP, every training program, every validation activity must exist twice. The mitigation is a hard sunset date for v3.2.2, driven by the last non-4.0 submission you plan to make in each region. Program governance should include a monthly review of the sunset milestone.

Risk: Legacy lifecycle migration blows up cutover

Forward compatibility from v3.2.2 to v4.0 sounds easy in the abstract. In practice, an in-flight v3.2.2 lifecycle with dozens of sequences and hundreds of lifecycle operations is a genuine data migration project17. Migration testing should include broken link checks, audit trail integrity, and side-by-side reviews of legacy sequences before and after conversion.

Risk: Gateway / EDT connectivity treated as an afterthought

FDA ESG, EMA gateway, PMDA, and Health Canada CESG each have their own connectivity models. FDA ESG in particular supports AS2, the Unified Submission Portal (USP), and API integration18. The v4.0 message payload changes; the gateway certification of your production endpoint may need to be revisited. Include a gateway smoke test in every pilot.

Risk: Program treated as an IT project

The most common structural failure is scoping the program with IT accountability and quality/regulatory advisory participation. The reverse is what works: regulatory operations and quality own the program, with IT as an executing partner. This ensures decisions about SOPs, training, and validation are treated as first-class program deliverables, not left to the last quarter.

Watch for silent risk accumulation. The risk profile of a v4.0 program shifts from technical (early) to operational (mid) to governance (late). Programs that measure only technical risk during pilots miss the operational readiness gap. Build the risk register with the operational and governance risks visible from month one, not month twelve.

Governance, Roles, and the Operating Model After Go-Live

The migration ends when v4.0 becomes routine. Getting there requires a governance model that can survive the shift from project mode to operational mode. Below is a practical structure that works for mid-sized sponsors.

Steering committee

Senior sponsorship from Regulatory Affairs, Regulatory Operations, Quality, and IT. Meets monthly during the program, quarterly after go-live. Owns the sunset milestone for v3.2.2 and the investment case for the program.

Program leadership

A single accountable program manager. Not a “coordinator”: a program manager with the authority to make schedule and scope calls. This role is best filled by someone with both regulatory operations depth and program management discipline. Sponsors often underestimate the seniority this role needs and later regret it.

Regional work streams

Each major region (FDA, EMA, PMDA, plus Health Canada and Swissmedic once they are active) needs a work stream lead. These are the people who understand the regional M1 IG, the region’s validation criteria, and the region’s gateway posture. In a boutique consulting engagement, this is the role that carries the most technical depth.

Tooling work stream

Publishing vendor management, RIM integration, DMS metadata, controlled vocabulary maintenance. This is the technical spine of the program. After go-live, this work stream becomes a permanent operational team, not just a project role.

SOP and training work stream

Rewrites SOPs, produces training materials, runs the training program, and is the internal answer to “how do we actually do this?” This work is chronically underinvested because it does not produce dashboards until late in the program, but it is what turns a technically successful cutover into an operationally successful one.

Change control and validation

Sits inside quality. Owns the validation deliverables for the publishing tooling, the RIM changes, and the gateway integration. In pharma companies with mature computer system validation practices, this work stream integrates cleanly into existing frameworks. In smaller sponsors, it may be a new muscle to build.

The operating model after go-live

Once v4.0 is in production, the goal is to compress the operational model to something sustainable. Typical structure:

  • A regulatory operations team that publishes in v4.0 as the default and can still publish in v3.2.2 for legacy sequences where forward compatibility is not yet available.
  • A regulatory technology function (one to three people, depending on volume) that owns vendor relationships, CV updates, and gateway health.
  • A quarterly governance forum that reviews KPIs (cycle time, reuse rates, agency queries, validation pass rates) and flags anything that requires steering committee attention.
  • A defined path to retire v3.2.2 capability by region, based on the last legacy sequence you expect to touch.

Signals that the operating model has stabilized. Publishing effort per sequence drops meaningfully (usually 15-30% for reused content). CV updates land within one release cycle. Validation pass rates on first pass approach 100%. Agency queries about eCTD structure become rare. Cross-region reuse of documents happens without special coordination. These are the markers that the migration paid off, not just that the milestone dates were hit.

Conclusion

eCTD 4.0 is the most significant change in submission architecture since the original eCTD standard. The good news is that the specification is mature, the agency roadmaps are visible, and the vendor ecosystem is investing. The harder news is that the transition is genuinely a program, not an upgrade. It touches publishing tooling, RIM systems, document management, gateway connectivity, controlled vocabularies, SOPs, training, and the day-to-day work of publishers, medical writers, and CMC authors. Sponsors that scope it accurately can compress it into an 18 to 24 month program with predictable milestones. Sponsors that under-scope it end up in dual-track operations for longer than planned, with higher costs and slower agency turnaround.

Sakara Digital works with pharma and biotech organizations building the regulatory operations capability that eCTD 4.0 demands, from dependency mapping and vendor evaluation through pilot design, SOP rewrites, and post go-live governance. If you are planning a v4.0 migration and want an independent perspective on where to start, or a second read on a program already in flight, we are happy to have that conversation.