A question worth asking now that the EASA Certification Platform is live

SEPIAC closed to external access on 14 July 2026. If you hold a DOA and you have Initial Airworthiness projects running with EASA, you are now working in the Certification Platform, whether or not you spent much time preparing for it.

The transition itself has been handled sensibly. EASA migrated active users and ongoing projects, published guidance ahead of time, and ran introduction webinars. Most applicants will find the mechanics familiar enough: you log in, you see your projects, you exchange documents with your certification team, you respond to comments. On the surface, it is the thing SEPIAC was, done better.

I would argue the surface is the least interesting part of it.

I was involved in the EASA testing and working group, and the conversations that stayed with me were not about features. They were about what happens to the certification relationship when the interface between applicant and authority stops being a document exchange and starts being a structured dataset, with a lifecycle. That shift is quiet, it is gradual, and it changes the economics of how a DOA runs its certification programmes.

This article is about that shift, and what I think it reasonably asks of applicants over the next two to three years.

What actually changed

SEPIAC was, in essence, a shared document space. It was a very useful one — it replaced email chains and file drop transfers, it gave both sides a single version of a document, and it made project status visible in a way that had not existed before. But its underlying model was files in folders with permissions attached. Structure lived in naming conventions and in the discipline of the people using it.

The Certification Platform is built on a different premise. EASA describes it as introducing structured data, workflow automation, task management, and integrated commenting, on top of the Agency's Digital Core infrastructure. The scope covers the full Initial Airworthiness range: Type Certificates, Supplemental Type Certificates, Major and Minor Changes, Major and Minor Repairs, and applications for parts and non-installed equipment including ETSO authorisations and ETSO minor changes.

The practical difference is that project state is now something the system knows, rather than something a human infers by looking at a folder. Who owns the next action. Which comment is open and which is closed. What stage a deliverable has reached. Where the clock is.

That is a genuine improvement, and it will make certification projects more predictable. It also has a second-order effect that I do not think has been widely discussed yet.

Structured data on one side creates pressure on the other

Structured data

When the authority side of a certification project becomes structured and queryable, the asymmetry with the applicant side becomes visible.

Consider what a typical SME DOA actually has when a project is running. The compliance matrix is a spreadsheet, maintained by one or two people, accurate as of the last time someone had a quiet afternoon. The means of compliance rationale for a particular paragraph lives partly in a document and partly in the memory of the engineer who wrote it. Document status is tracked in a second spreadsheet, or in the file naming convention, or in someone's head. Open actions are in a meeting minutes template. The link between a CS paragraph, the MoC selected for it, the evidence produced, and the approval status of that evidence is real — but it is reconstructed on demand rather than maintained continuously.

None of this is negligence. It is the rational outcome of small teams under delivery pressure using the tools they have. It worked because the interface to the authority absorbed the ambiguity: you produced a compliance document, you uploaded it, and the structure existed inside the document.

That absorption capacity is shrinking. As the platform's structured model deepens — and EASA has published a fairly clear roadmap here, including Master and Project CRI management, digital certificates, and enhanced reporting and dashboards — the expectation moves toward applicants being able to answer structured questions about their own compliance position, at the granularity the system operates at, at any moment.

The organisations that will find this comfortable are the ones whose internal compliance picture is already structured. The organisations that will find it painful are the ones that will now be reconstructing that picture more often, under more time pressure, for an audience that can see inconsistencies more easily than before.

The machine-to-machine question

Buried in EASA's stated roadmap is a line that deserves more attention than it has received: future enhancements include machine-to-machine integration.

Think about what that implies. Today, the boundary between your internal systems and the Agency's is a human being who exports something, reformats it, and uploads it. If that boundary becomes an API, then the quality of your internal data model stops being an internal matter. It becomes the thing that either connects cleanly or does not.

This is not a near-term concern — it is signposted as a later phase, and EASA has been explicit that the platform will keep evolving over the coming months and years. But it is a directional signal, and directional signals are worth acting on early when the thing they point at takes years to build.

If your compliance data is a set of spreadsheets, you cannot integrate it. If your requirement-to-evidence traceability exists only as a rendered document, you cannot expose it directly. The organisations that will be able to take advantage of machine-to-machine certification workflows in 2029 are the ones that start structuring their compliance data in 2026.

What I would actually do now

Setting strategy aside, here is the practical near-term list.

Sort out access properly, not minimally. Access to the platform runs through EASA Connect, with users needing Contributor rights assigned by your organisation's Account Administrator, who then assigns people to the Applicant Team for each project. The failure mode here is obvious and predictable: one person holds administrator rights, that person goes on leave, and a project stalls because nobody can add the new stress engineer to the team. Name a deputy. Document the process in your procedures. Treat it as a role in your Design Management System rather than an IT afterthought.

Check your migrated projects against your own records. EASA migrated ongoing projects, and migrations have been, at least in my experience, only "generally reliable". But if your project was unstructured in SEPIAC and the EASA positions were unstructured too, you might have ended up very well with a bunch of files in the project repository rather deliverables for the It can be frustrating to have to assign somebody in your organisation to confirm that what is in the platform matches what you believe the project state to be and rebuild it — open items, document versions, outstanding comments. But it is better to do it now, while the transition is recent enough that discrepancies are still explicable. And you can use this as an opportunity to have a look at your own data...

Ask an uncomfortable internal question. If a certification team member asked you today for the current compliance status of your largest active project — paragraph by paragraph, with evidence status and open items — how long would it take, and how confident would you be in the answer? Not how long should it take. How long does it take. That number is your real exposure, and it does not change because the authority's tooling improved.

Separate the two problems in your own mind. The platform manages the interface between you and EASA and offers you transparency in how EASA manages the projects. It does not manage your internal compliance picture, and it is not designed to. Those are different problems with different owners. Mixing them is the mistake I expect to see most often over the next eighteen months — organisations assuming that because the authority side is now well-structured, their side is somehow handled.

The broader point

Regulators digitalising is usually framed as an efficiency story: fewer emails, faster turnarounds, better visibility. All of that is true and welcome.

But there is a second story underneath it. Every step the authority takes toward structured, queryable, automated certification data raises the baseline for what a competent applicant looks like. Not through any change in the regulation — Part 21 asks what it has always asked — but through a change in what is easy to see.

Compliance documentation and compliance demonstration were always different things. The first is a set of artefacts. The second is the ability to show, coherently and on demand, that the artefacts add up to a certified design. And the rational behind it. Most organisations have managed the gap between them by relying on the fact that nobody could see it in real time.

That is the assumption the Certification Platform is slowly retiring.

I do not think this is cause for alarm. The direction is right, the Agency has been transparent about the roadmap, and the transition has been managed better than most. But I do think it is cause for a deliberate look at your own side of the boundary, while the pressure is still low.