EMA's web-based eAF mandate needs a technical-exception and submission-receipt record
EMA says the PLM web-based electronic Application Form becomes mandatory for human Centrally Authorised Product variation submissions on September 1, 2026, with justified technical exceptions for continued interactive-PDF use. Regulatory operations need to preserve the applicable form path, impediment, support evidence, submission package, and receipt outcome as separate controlled facts.
Editorial figure by RegQuality Review. Source context: EMA Electronic Application Forms.
Bind the mandate to the exact procedure
The direct answer is that the September 1 control should be represented as a procedure-specific submission rule, not as a universal ban on every interactive PDF eAF. EMA's notice addresses human Centrally Authorised Product variation submissions sent to EMA. The governed record should identify product, procedure and variation, authority, submission date and deadline, form purpose, required channel, form or service version, and the controlling notice reviewed by the regulatory owner.
Related eAF timelines on the same official page differ by human or veterinary use, application type, centralized or national procedure, authority, form version, and implementation date. A rules table should keep those dimensions visible and effective-dated. Applying a single global status such as web form required can route an unaffected procedure incorrectly, while relying on a historic project default can send a newly governed CAP variation through a rejected path.
Make the technical exception an evidence package
EMA lists known circumstances that may prevent correct finalization of the web-based form, including performance limits for very large applications, a Medical Devices section issue, PMS or OMS data problems, lack of required portal access, and other blocking technical issues. The exception record should state the actual impediment, affected form and products, onset, reproduction evidence, deadline impact, available workaround, owner, and reason the PDF route was necessary. Selecting a generic exception label is not enough.
Where a service-desk ticket is appropriate, preserve its identifier, timestamps, evidence supplied, response, estimated resolution, and relationship to the filing deadline. EMA's page also distinguishes known limitations that do not require a ticket from issues for which users should seek support. The organization's procedure should capture that distinction without inventing a regulator approval that the source does not describe. A technical exception authorizes a route under stated conditions; it does not validate the application content.
Separate form generation, package delivery, and acceptance
A completed PLM form is not yet a delivered submission, and a delivered package is not necessarily accepted for processing. Controlled evidence may include the web-form identifier and version, PMS data snapshot or reference, contributors and roles, finalization time, exported artifact and checksum, dossier sequence, technical validation result, transmission receipt, gateway acknowledgement, authority message, rejection, and any corrected resubmission. Each status should retain its source system and event time.
The same separation matters for an exception PDF. The package should link the justification without merging it into the form or treating a successful upload as agreement that the reason was valid. If the authority rejects the route, the record should retain the submitted package, rejection basis, corrected web or PDF form, resubmission, and changed deadlines. A clean audit trail lets reviewers explain both the procedural choice and the actual submission outcome.
Test one deadline across normal and exception paths
A representative readiness test should create a human CAP variation in the web-based eAF, introduce a PMS data defect that blocks finalization, record the applicable support route, approach the filing deadline, generate an exception PDF, and simulate both rejection and accepted resubmission. Reviewers should reproduce the controlling rule, users and permissions, product data, form versions, impediment, ticket or known-limit rationale, package, receipts, and superseded attempt.
EMA's official eAF page supports the stated September 1 mandate, identified technical limitations, exception positioning, user-access and PMS-data preparation, and rejection warning. It does not establish a sponsor's product data, access, exception validity, application completeness, submission delivery, technical acceptance, procedural acceptance, approval, or market authorization. Qualified regulatory, product-data, quality, information-technology, privacy, security, compliance, and legal owners retain their decisions.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
RegQuality Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.