eCTD v4.0 is coming. Why this is more than a submission format upgrade.

Where the EU transition stands

eCTD v4.0 is no longer a specification waiting for a start date. It is in use, on a published roadmap, and the dates that matter are close enough to plan against.

That distinction matters because older roadmaps and third-party articles still say 2027 mandatory, and they still rank in search results. Check the eSubmission site before quoting a date in a plan — the published timeline has moved before and can move again.

Is eCTD v4.0 mandatory in the EU in 2027? No. On EMA's current roadmap for new centrally authorised MAAs, use is expected to be strongly recommended from Q1 2027, with mandatory use planned from Q1 2028. Timelines for forward compatibility and for non-centralised procedures depend on testing outcomes and are still being updated.

What actually changes between eCTD 3.2.2 and v4.0

In eCTD 3.2.2, meaning comes largely from position. A document is what it is because of the folder it sits in, the file name it carries and the lifecycle operation — new, replace, delete — applied to it in a sequence.

eCTD v4.0, built on the HL7 Regulated Product Submission standard, moves that meaning into metadata. Content is described by a context of use that links a document to a CTD heading, with controlled-vocabulary keywords describing what it is. EU Module 1 becomes a single folder with no additional folder structure, and its file and folder naming conventions are replaced by keywords at context-of-use level. Regulatory activity, submission unit and product information are tracked through identifiers — UUIDs at different levels — rather than by position in a tree.

Lifecycle changes shape too. Instead of replacing a file in place, a new context of use is inserted with the right keyword combination and a priority number; content that is no longer relevant is suspended, and content that needs adjusting is replaced. In the EU region a submission unit cannot itself be deleted or suspended to handle a withdrawal or rejection.

The submission becomes less about where a file sits and more about what the regulatory system knows that file represents.

New applications are the easy part. Existing lifecycles are harder.

A new marketing authorisation application can start cleanly in v4.0. Most products cannot. They carry years of eCTD 3.2.2 history — variations, renewals, responses, product-information updates — and that history has to remain usable after the format changes.

That is what forward compatibility means, and it is the part still being worked out. EMA's pilot, launched in March 2026, identified technical challenges that are being addressed, and a further pilot phase is planned for Q4 2026 subject to the readiness of tools and systems. EMA also states that the timeline for products with an existing v3.2.2 lifecycle depends on the outcome of testing and further readiness assessments.

Read that as a signal rather than a delay. A regulator still testing how existing dossiers move forward is telling you this is not a routine publishing upgrade, and that the migration question belongs in your 2027 planning rather than in a vendor's release notes.

The publishing team cannot solve this alone

eCTD has traditionally been owned by regulatory operations and the publishing vendor. With v4.0 that ownership is too narrow, because what has to be right is upstream information: identifiers, controlled-vocabulary terms, the relationships between applications, activities and documents.

Getting those right needs regulatory affairs (what the content means), regulatory operations (how it is assembled), RIM and master data (what the identifiers point to), document management (where content lives and how it is versioned), the publishing vendor (tool support for the current validation criteria) and IT (the integrations between all of it). If those functions disagree about what a product, application or activity is called, v4.0 will surface that disagreement as a validation problem.

Document reuse sounds simple. Governance isn't.

One of the clearest benefits of v4.0 is reuse: sharing the same document across different contexts of use, and across applications where the content is identifiable through an eCTD v4.0 compliant identifier, instead of submitting the same PDF many times. EMA's practical guidance gives the everyday example of a document that applies to several manufacturers, where separate contexts of use can carry manufacturer-specific keywords rather than duplicating the file.

The regulatory questions that follow are not technical:

• When the document changes, which applications and activities reference it?
• Is the reused document still valid in every regulatory context it appears in?
• Who owns the relationship — the authoring function, or the application it was first submitted under?
• How do you avoid assuming that identical content carries identical regulatory meaning in a different procedure or market?
• How is a reuse decision recorded so that a reviewer can reconstruct it later?

Reuse removes duplication. It does not remove the obligation to know what each copy meant.

Metadata is becoming regulatory data

When a submission depends on controlled terms, identifiers, keywords and declared relationships, a metadata error stops being an administrative untidiness. It becomes a submission-quality issue: content filed against the wrong heading, a lifecycle operation that points at the wrong predecessor, or a reference that cannot be resolved at all.

This is the same shift we wrote about for electronic product information, and it is not a coincidence. EMA's quarterly system demo on 17 September 2026 ran eCTD v4.0, the Product Management Service, ePI, the Union Product Database and EudraGMDP in a single agenda. These are not three or five unrelated IT projects; they are one direction of travel.

Documents are not disappearing. But more of the regulatory meaning around them is being expressed as structured information that systems exchange and reuse — which is exactly why data governance is now a regulatory affairs topic rather than an IT one.

What this means for AI in regulatory work

Today an AI system reading a dossier usually starts from PDFs: extract text, infer the structure, guess which section a passage belongs to and which version it came from. Structured submissions remove much of that guesswork — a known application, a known regulatory activity, a known context of use, a known document relationship.

That is better ground for anything automated: consistency checks across an application, change detection between activities, impact analysis after a variation, and retrieval that can cite exactly what it used. The caveat is the same one we apply everywhere: structured data reduces ambiguity, it does not create regulatory truth. A perfectly valid message can still describe the wrong thing, and someone qualified still has to say whether the content is right.

eCTD v4.0 readiness questions for 2026

None of these depend on the final mandatory date. All of them take longer than a release cycle.

1. Does your publishing vendor support the current EU eCTD v4.0 validation criteria, applicable since 15 July 2026?
2. Have you assembled and validated a new CAP MAA in v4.0, even as a test?
3. Who owns the transition plan for existing v3.2.2 lifecycles — and is it a named owner, not a vendor?
4. Has regulatory operations taken part in, or at least tracked, the forward-compatibility pilots?
5. Are your document identifiers and metadata reliable enough to be exchanged rather than displayed?
6. How does your RIM system map to submission metadata: applications, activities, products, contacts?
7. Which SOPs assume 3.2.2 concepts — folder structure, file naming, delete operations — that change in v4.0?
8. Are controlled vocabularies governed centrally, or maintained per team?
9. Do your archive and document systems understand reuse, or will they copy files anyway?
10. Do you have a plan for the Q1 2027 strongly-recommended milestone, rather than for the Q1 2028 mandatory one?

Our view: don't make 2027 the year you start preparing

A mandatory date in Q1 2028 invites complacency, and the roadmap argues against it. Strong recommendation starts a year earlier. Validation criteria are already applicable. Pilots are running now, and the forward-compatibility work that most affects existing portfolios has open technical issues. Non-CAP procedures are only entering technical piloting.

2028 is a deadline. It should not be the implementation plan. The work that takes real time — data quality, identifiers, vocabularies, ownership, SOPs — is the work that has no deadline attached to it, which is exactly why it slips.

Where RafiHive fits

Regulatory digitalisation makes it harder, not easier, to know which version of a requirement applies. Specifications, validation criteria, practical guidance and roadmaps all move on their own schedules, and last year's date is still online. RafiHive answers from a reviewed knowledge base of official EU/EEA sources with each document's status and version recorded, cites what it used, and reports missing evidence instead of filling the gap. The Module 1 gap check works on the same principle for a submission you are preparing today.