Interoperable Europe Act 2024: The Developer's Guide to EU Public Sector API Compliance

If you build software for EU public sector customers — ministries, municipalities, agencies, hospitals, universities — a regulation that entered into force on September 11, 2024 directly affects what your APIs, data models, and hosting infrastructure must look like. Most developers building in this market have not heard of it.

The Interoperable Europe Act (IEA), Regulation (EU) 2024/903, replaces the decade-old ISA² programme and creates legally binding interoperability requirements for public sector IT systems. For the first time, private SaaS vendors whose products are used by public sector entities to implement EU law must be able to demonstrate compliance with European Interoperability Framework (EIF) standards — including API design, data formats, identity integration, and open-source licensing norms.

This guide covers what the IEA requires, which obligations apply to your product as a vendor, and the concrete technical changes you need to make if you sell into EU public sector.

What Is the Interoperable Europe Act?

The Interoperable Europe Act (Regulation (EU) 2024/903) was published in the Official Journal on April 11, 2024 and entered into force on September 11, 2024. It creates a permanent legal framework for cross-border interoperability of EU public sector network and information systems.

The IEA replaces the ISA² programme, which funded interoperability projects but lacked legal enforcement. The new regulation is binding EU law with mandatory obligations, a governance structure (the Interoperable Europe Board), and a formal registry of reusable solutions (the Interoperable Europe Portal).

The stated goal is practical: an EU citizen using a digital identity wallet in Germany should be able to access public services in France; a hospital in Austria should be able to exchange patient records with a clinic in Spain without custom integration. Achieving this requires that all underlying IT systems speak compatible standards — which means every vendor building software on top of public sector infrastructure must align to those standards.

Scope: Who Does the IEA Apply To?

Article 4 of the IEA defines the scope. It applies to:

Directly in scope:

EU institutions, bodies, offices, and agencies (EUIBAs)
Public sector bodies of EU Member States when implementing EU law via network and information systems

Indirectly in scope:

Private entities providing IT systems, software, or services to the above (you)

The indirect scope is the commercially important one. If your SaaS product is used by a German Bundesministerium, a French prefecture, a Dutch municipality, or any EU public hospital implementing EU directives, your product's interoperability characteristics become part of that public body's compliance posture.

Public sector procurement increasingly includes IEA-alignment as a technical selection criterion. The 2025 revision of the EU Public Procurement Regulation explicitly references IEA standards for IT system tenders above €150,000. If you cannot demonstrate compliance, you lose bids.

The Five Core Obligations That Affect Vendor Products

1. Interoperability Assessments (Article 8)

Before deploying new network and information systems — or significantly modifying existing ones — that are used to implement EU law, public sector bodies must conduct a mandatory interoperability assessment. This assessment evaluates cross-border interoperability against EIF standards.

The practical impact for vendors: your customer will run this assessment, and they will assess your product. If your APIs use proprietary data formats, require vendor-specific authentication flows, or cannot exchange data with other certified systems on the Interoperable Europe Portal, the assessment fails — and your customer may not be able to deploy your product.

Your product documentation must include enough technical detail to complete an interoperability assessment without access to your source code. This means published OpenAPI specifications, documented data model mappings, and explicit statements of which SEMIC Core Vocabularies your data exports use.

Public sector bodies that develop or commission interoperability solutions — software, APIs, data models, semantic assets — must make these solutions available on the Interoperable Europe Portal (interoperable-europe.eu). The obligation applies to solutions developed with public funding.

For vendors, Article 9 has a reuse corollary: public sector procurement criteria increasingly require that solutions use components already listed on the Interoperable Europe Portal rather than building proprietary equivalents. If you are building an identity layer, a document exchange API, or a notification service for public sector customers, check whether a certified solution already exists on the Portal. Building on it — rather than proprietary alternatives — can be a procurement differentiator.

3. Open-Source Licensing and Joinup (Article 9(3))

Software developed under IEA-aligned public contracts must be released under an open-source licence approved by the Open Source Initiative unless specific exceptions apply (national security, third-party IP). The preferred repository is Joinup (joinup.ec.europa.eu), the EU's open-source platform.

For SaaS vendors, this does not mean your entire product must be open-source. But any custom components, adaptors, or integrations developed specifically for a public sector customer under a public contract may need to be released under EUPL (European Union Public Licence) or compatible licences. If your contract includes co-development, understand which components fall under Art.9(3) scope before signing.

4. Peer Reviews (Article 12)

Public sector entities can request peer reviews of their interoperability posture. The Interoperable Europe Board can also commission reviews. Peer reviews examine whether deployed systems meet EIF standards and IEA obligations.

The vendor implication: if your customer is reviewed and your product is the integration point under scrutiny, the review team will ask for technical documentation of how your system handles cross-border data exchange. Have this ready: API specifications, data lineage documentation, and access control architecture aligned with EIF Layer 4 (Technical Interoperability).

5. Regulatory Sandbox for Innovative Solutions (Article 13)

The IEA establishes a regulatory sandbox that allows vendors to test innovative interoperability solutions in a controlled environment with reduced compliance obligations during testing. Applications go through the Interoperable Europe Board.

This is directly relevant for vendors building novel GovTech products — federated identity systems, cross-border data spaces, AI-assisted document processing for public administration. The sandbox lets you validate your architecture against EIF standards before committing to full production compliance.

The Technical Stack: What EIF Compliance Actually Requires

The European Interoperability Framework (EIF) — the technical standard that the IEA enforces — defines interoperability across four layers. Your product must address all four.

Layer 1: Legal Interoperability

Your contracts with public sector customers must explicitly authorise cross-border data exchange. This means your Data Processing Agreements (DPAs) cannot restrict data to a single jurisdiction without an exception process. It also means your terms of service must not prevent a German agency from sharing outputs with a French counterpart under a bilateral agreement.

GDPR intersection: cross-border data exchanges involving personal data still require the usual GDPR transfer mechanisms (adequacy decision, SCC, BCR). IEA and GDPR are additive — IEA creates an obligation to enable cross-border interoperability; GDPR governs how personal data crosses borders. Both must be satisfied simultaneously.

Layer 2: Organisational Interoperability

Business process alignment. Your product must be able to participate in workflows that span multiple public sector entities and potentially multiple Member States.

Practical requirements:

Process documentation in machine-readable BPMN (Business Process Model and Notation) format
Service catalogue entries in DCAT-AP (Data Catalogue Vocabulary Application Profile) format
Role-based access control aligned with the Public Organisations Ontology (ORG)

If your product includes workflow configuration, export your process models in BPMN 2.0 XML. If it includes a service catalogue or API directory, publish it in DCAT-AP 3.0 format.

Layer 3: Semantic Interoperability

Data meaning must be shared across systems. The EU's SEMIC (Semantic Interoperability Community) publishes Core Vocabularies that define standardised data structures for the most common public sector data objects.

The five Core Vocabularies you are most likely to encounter:

Vocabulary	Covers	Namespace
Person Core Vocabulary	Individuals, identity, addresses	`http://www.w3.org/ns/person#`
Business Core Vocabulary	Organisations, legal entities	`http://www.w3.org/ns/regorg#`
Location Core Vocabulary	Addresses, geographic identifiers	`http://www.w3.org/ns/locn#`
Public Service Core Vocabulary	Government services, eligibility, channels	`http://data.europa.eu/m8g/`
Evidence Core Vocabulary	Documents, attestations, proofs	`http://data.europa.eu/m8g/`

If your product stores or exchanges data about people, organisations, addresses, or government services, map your internal data models to the relevant Core Vocabulary. This does not mean you must store data in RDF — it means your export formats and API responses must be translatable to Core Vocabulary representations when your public sector customer needs them for cross-border exchange.

# Example: Mapping a user record to Person Core Vocabulary for export
def export_person_core_vocabulary(user: dict) -> dict:
    return {
        "@context": "http://www.w3.org/ns/person#",
        "@type": "Person",
        "identifier": {
            "@type": "adms:Identifier",
            "notation": user.get("national_id"),
            "schemeAgency": user.get("issuing_country", "EU")
        },
        "familyName": user.get("last_name"),
        "givenName": user.get("first_name"),
        "birthDate": user.get("date_of_birth"),
        "address": {
            "@type": "locn:Address",
            "fullAddress": user.get("full_address"),
            "adminUnitL1": user.get("country_code"),
            "postCode": user.get("postal_code")
        }
    }

Layer 4: Technical Interoperability

The API and infrastructure layer. This is where most developers will spend the most implementation time.

API requirements:

REST + OpenAPI 3.1: All APIs serving public sector customers must have published OpenAPI specifications. No proprietary API description formats.
OAuth 2.0 / OpenID Connect: Authentication must use open standards. Proprietary SSO systems are not acceptable for cross-border scenarios.
eIDAS 2.0 compatibility: If your product handles identity (login, digital signatures, attestations), you must support the EU Digital Identity Wallet (EUDIW) protocol stack. The EUDIW uses OpenID4VCI (Verifiable Credential Issuance) and OpenID4VP (Verifiable Presentation).
HTTPS / TLS 1.3: Required baseline. TLS 1.0 and 1.1 are explicitly prohibited in EIF technical guidelines.

Data exchange formats:

JSON-LD for semantic data exchange
DCAT-AP 3.0 for metadata and catalogue entries
BPMN 2.0 XML for process documentation
XBRL (if financial reporting is in scope for your domain)

Accessibility:

WCAG 2.2 Level AA for all user interfaces (also required by the European Accessibility Act, which applies from June 28, 2025 for SaaS)

# OpenAPI 3.1 fragment showing IEA-aligned API metadata
openapi: 3.1.0
info:
  title: Public Service API
  version: 1.0.0
  x-interoperable-europe:
    eia-assessed: true
    assessment-date: "2025-11-01"
    eif-layers: [legal, organisational, semantic, technical]
    core-vocabularies: [Person, Business, PublicService]
    portal-entry: "https://interoperable-europe.eu/solution/your-api"
  license:
    name: EUPL-1.2
    url: https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12

The Interoperable Europe Portal: Registering Your Solution

The Interoperable Europe Portal (interoperable-europe.eu) is the official EU registry for reusable interoperability solutions. Registering your product or APIs on the Portal is not mandatory for private vendors, but it is a significant commercial advantage in public sector procurement:

Visibility: Public sector procurement officers search the Portal for certified solutions. Listing increases discoverability.
Procurement preference: IEA Article 9 creates a "reuse first" principle. A Portal-listed solution is treated as a preferred alternative to proprietary development.
Trust signal: Portal registration implies the solution has been reviewed for EIF alignment.

To register on the Interoperable Europe Portal:

Create an account on Joinup (joinup.ec.europa.eu)
Submit your solution via the Portal's solution submission form
Provide OpenAPI specification, Core Vocabulary mapping documentation, and licensing information
Await validation by the Portal editorial team (typically 4-8 weeks)

Registration is free. The editorial review focuses on documentation completeness and EIF layer coverage — not a formal conformity assessment.

The IEA creates obligations to share data. GDPR creates obligations to protect personal data. These are not inherently in conflict, but the intersection requires careful architecture.

The key tension: IEA promotes open data exchange and reusable solutions. GDPR requires a lawful basis for each personal data processing activity, including transfer to other public bodies.

Practical rules:

If your product enables data exchange between public sector bodies, build explicit consent/basis tracking into the data flow. Each cross-border exchange involving personal data needs a documented legal basis.
GDPR Article 6(1)(e) (task in the public interest) is the most common basis for public sector data exchanges. Ensure your DPA with the public sector customer clearly identifies this basis.
Personal data that is exchanged in IEA-compliant formats (JSON-LD, Core Vocabularies) is still personal data under GDPR. Pseudonymisation is recommended before cross-border exchange unless the destination entity has a documented legal basis.
Build audit logging into your cross-border data exchange endpoints. GDPR Article 5(2) accountability requires you to demonstrate compliance, and IEA peer reviews may request exchange logs.

# Pattern: Audit-logged cross-border data exchange
import logging
from datetime import datetime, timezone

audit_log = logging.getLogger("iea.exchange")

def exchange_data_cross_border(
    payload: dict,
    source_entity: str,
    destination_country: str,
    legal_basis: str,
    data_subject_id: str | None = None,
) -> dict:
    audit_log.info({
        "event": "cross_border_exchange",
        "timestamp": datetime.now(timezone.utc).isoformat(),
        "source": source_entity,
        "destination_country": destination_country,
        "legal_basis": legal_basis,
        "data_subject_id": data_subject_id,  # pseudonymised ID if personal data
        "payload_schema": payload.get("@context"),
        "gdpr_art6_basis": legal_basis,
    })
    # ... actual exchange logic
    return {"status": "sent", "exchange_id": generate_exchange_id()}

Cloud Hosting: Why IEA Favours EU-Native Infrastructure

The IEA does not mandate EU hosting for all public sector systems. But a combination of IEA, GDPR, and national IT security requirements creates strong practical pressure toward EU-hosted, CLOUD Act-free infrastructure.

The pressure comes from three directions:

1. GDPR Article 48 + CLOUD Act conflict. US cloud providers remain subject to CLOUD Act orders that can compel data disclosure without notifying the data subject or the EU public sector body that contracted for the service. This creates a structural tension with GDPR Article 48, which prohibits transfers based on foreign court orders unless an EU-recognised mechanism applies. IEA-compliant cross-border data exchanges involving personal data cannot route through infrastructure subject to unilateral US government access.

2. NIS2 Article 6 and sovereign infrastructure requirements. Critical entities (health, energy, public administration) under NIS2 must implement measures to manage third-country ICT supply chain risks. Routing public sector data through US-jurisdiction cloud introduces a risk that NIS2 requires to be assessed and mitigated.

3. IEA procurement criteria. While the IEA does not mandate EU hosting, the European Commission's guidance for public sector IT procurement explicitly identifies "data sovereignty" and "CLOUD Act exposure" as risk factors to be assessed in vendor selection. This is increasingly reflected in tender specifications.

The practical result: EU public sector procurement increasingly filters out vendors whose infrastructure runs on US-hyperscaler public cloud with no EU-jurisdiction guarantee. EU-native infrastructure — hosted in EU data centres, operated by EU-incorporated entities, not subject to US CLOUD Act jurisdiction — becomes a technical requirement rather than a preference.

10-Item IEA Compliance Checklist for SaaS Vendors

#	Requirement	Source
1	Publish OpenAPI 3.1 specification for all public-sector-facing APIs	EIF Layer 4
2	Map internal data models to relevant SEMIC Core Vocabularies	EIF Layer 3
3	Support OAuth 2.0 / OIDC for authentication	EIF Layer 4
4	Implement eIDAS 2.0 wallet compatibility for identity flows	EIF Layer 4
5	Document BPMN 2.0 process models for all public sector workflows	EIF Layer 2
6	Publish DCAT-AP 3.0 metadata for APIs and datasets	EIF Layer 2
7	Implement HTTPS / TLS 1.3 minimum, disable TLS 1.0/1.1	EIF Layer 4
8	Meet WCAG 2.2 Level AA for all user interfaces	EIF + EAA
9	Provide interoperability assessment documentation on request	IEA Art.8
10	Assess whether EU-native hosting is required under NIS2/GDPR/procurement criteria	GDPR + NIS2

Getting Started: Priority Actions for Vendors

If you are actively selling into EU public sector and have not yet assessed your IEA posture, the three highest-priority actions are:

Priority 1 — Publish your OpenAPI specification. This is the most common documentation gap identified in public sector interoperability assessments. An unpublished or incomplete API specification blocks the assessment process entirely. Publish a full OpenAPI 3.1 spec for every API your public sector customers use, and link it from your documentation and your DCAT-AP metadata.

Priority 2 — Map your data models to Core Vocabularies. Build a mapping table that shows which of your internal data fields correspond to which Core Vocabulary terms. You do not need to change your internal storage format — you need to be able to export in Core Vocabulary format on request. Publish this mapping in your developer documentation.

Priority 3 — Review your hosting configuration. Check whether your infrastructure introduces CLOUD Act exposure. If you are running on AWS, Azure, or GCP without a verified EU-jurisdiction contractual arrangement, assess whether your public sector customers' NIS2 and IEA risk profiles require a change. EU-native PaaS alternatives — including EU-headquartered providers with GDPR-aligned infrastructure — are now a competitive requirement in many tenders, not a premium add-on.

The Interoperable Europe Act has been in force for eight months. Most SaaS vendors building for EU public sector have not yet assessed their alignment. The regulation's enforcement mechanism runs through procurement — non-compliant vendors lose bids. For each open tender your product could win, IEA-alignment is now part of the technical scoring rubric.

The documentation work required — OpenAPI specs, Core Vocabulary mappings, DCAT-AP metadata — is largely a one-time effort. The infrastructure assessment (CLOUD Act exposure, EU hosting requirements) may require a larger architectural decision. Both are easier to address before you are mid-tender than after.