Where Apache APISIX fits DORA Article 9 at the API layer
An APISIX gateway helps a financial entity meet the parts of DORA Article 9 that touch the API layer: strong authentication enforcement, encryption in transit, segmentation of routes and control over gateway configuration. It does not meet Article 9 on its own. Governance, the ICT risk assessment, monitoring of the whole ICT estate and the register of information on ICT third-party arrangements sit outside the gateway. DORA also sets no certification scheme, so no product makes an entity compliant. DeployOpen plans, builds and documents the gateway and prepares the evidence an entity needs for its own supervisory file, but independent auditors and the competent authority make any assessment.
Consider a financial entity exposing payment initiation, account balance and partner onboarding APIs to third parties, while internal services call the same back ends. A supervisor asking how the API layer meets Article 9(4) will want to see which routes require authentication, which identity provider validates them, where TLS terminates and how that is configured, and whether internal services sit behind separate routes or separate gateway instances. In APISIX these answers live in route and plugin definitions, consumer objects and the apisix.yaml or Admin API configuration, so the entity should confirm early which of its APIs will be published through the gateway and which will stay on private paths.
Configuration control is where the gateway most often creates work. Under Article 9(4)(e), every change to routes, plugins and certificates must be recorded, tested, approved and verified. Choose one source of truth before go-live, either the Admin API with change records, or declarative files in version control in standalone mode, and confirm with your team how the Admin API on port 9180 is restricted in traditional mode. Plan the segmentation with the network team as well, because Article 9(4) expects the connection infrastructure to be severable, and a gateway that is the only path into a critical function is the first thing a supervisor will test.
Mapping Article 9 requirements to APISIX capabilities and configuration
This table maps each Article 9 requirement that applies to the API layer to the APISIX capabilities that can address it and the settings your team must define. It describes documented capabilities only, so confirm each mapping in your own environment and against your ICT risk assessment before relying on it as evidence.
| Requirement | APISIX capability | Configuration you must define |
|---|---|---|
| Article 9(1) and (2): continuous monitoring and protection of data in transit | HTTPS and HTTP/3 with QUIC for client traffic; gateway logs and observability plugins that record API access | TLS termination points, approved protocol versions and cipher policy, certificate lifecycle ownership, log destinations and alert thresholds for anomalous API traffic |
| Article 9(4)(d): strong authentication | openid-connect plugin with Keycloak, Microsoft Entra ID, Okta and other identity providers; key-auth, jwt-auth and client certificate options | Which routes require authentication, the authorization code, client credentials or introspection flow used, token validation rules, and how consumers and their credentials are issued and revoked |
| Article 9(4)(e): protection of cryptographic keys and encryption by data classification | TLS configuration per route; certificate and key storage through the configuration store; Admin API access restricted to the admin port | Data classes mapped to required encryption, key custody and rotation owner, etcd encryption and access rules, and which routes carry data that needs mutual TLS |
| Article 9(4)(f): documented change management and patch policy | Configuration held as files in standalone mode, so changes can be version controlled; Admin API changes can be scripted; release versions published on the downloads page | Change approval workflow, test environment for gateway configuration, upgrade and patch cadence, and records of who applied each change and when |
| Second subparagraph of Article 9(4): network connections that can be severed or segmented | Traditional mode separates client traffic on port 9080 from the Admin API on port 9180; decoupled mode separates data plane from control plane; standalone mode runs without etcd | Network policies that restrict port 9180 to admin networks, placement of data plane and control plane in separate segments, documented procedure to block a route or consumer quickly, and tested failover |
| File-driven standalone reload behavior | Standalone mode checks the configuration file every second and hot-reloads changes without a restart | Whether hot reload is acceptable for each change type, validation before a file is deployed, and who may write the file on each gateway node |
Evidence an APISIX gateway can produce for Article 9 reviews
Article 9 reviews ask whether ICT changes are controlled, access is authenticated and recorded, and the network can be segmented. The cards below list the records a gateway deployment can produce, how to keep each one, and which function in the organization should own it. Confirm each item in your own environment before relying on it in a review, because what APISIX writes by default depends on your logging, plugin and storage choices.
Versioned route and plugin configuration
The live gateway behavior is defined by routes, upstreams, consumers and plugin settings. In traditional mode this state sits in etcd, while in file-driven standalone mode it sits in conf/apisix.yaml or conf/apisix.json. For Article 9(4)(e) evidence, keep the declarative source in a version control system and compare it with the running state on a schedule. Confirm with your own deployment whether a configuration export from the Admin API or etcd can be taken and retained. Platform engineering should own this record, with the security function reviewing changes that touch authentication or encryption settings.
Change records tied to approvals
Article 9(4)(e) expects every change to be recorded, tested, assessed, approved, implemented and verified. Gateway changes should travel through a pull request that links the test run, the risk assessment and the approver, and the merge should be the only path that updates the configuration. Ask your team whether direct Admin API writes are blocked in production, since an out-of-band change would leave a gap in the record. Change management owns the approval workflow, and the gateway team owns the link between each pull request and the deployed revision.
Access logs and authentication decisions
Strong authentication under Article 9(4)(d) can be evidenced by showing which consumer or identity was accepted or rejected on each route. Plugins such as openid-connect, jwt-auth and key-auth determine these decisions, so the record depends on which plugins protect each route and how the access log format is configured. Confirm which fields are written, where logs are sent, how long they are retained, and whether tokens or personal data are masked. Security operations should own the log pipeline, and the identity team should own the mapping of identities to consumers.
Certificate and key inventory
Article 9(4)(d) requires cryptographic keys to be protected and encryption to match data classification. An inventory should list every TLS certificate on the gateway, its issuer, its expiry, the private key location, and the upstream services that trust it. Check how keys are stored, whether the Admin API key is rotated, and how certificate renewal is tested before expiry. The security or PKI team should own the inventory, and the gateway team should own the renewal procedure and its test results.
Segmentation and failover test results
Article 9(4), second subparagraph, requires the network to be segmented or severed quickly to limit contagion, and Article 9(1) requires resilience of critical functions. Keep dated test records showing that a route can be disabled, that traffic is blocked between zones except through the gateway, and that a node or etcd failure leads to the expected behavior. Record the test scope, the result and the remediation. Operations should run these tests, and the resilience or risk function should review and sign off on the results.
How the gateway enforces authentication and segmentation
A client request to an API behind APISIX passes through the gateway before it reaches any upstream service. APISIX matches the request to a route, runs the plugins attached to that route in order, and only then forwards the request to the upstream. Authentication plugins such as key-auth, jwt-auth or openid-connect run in this request phase, so an unauthenticated request should be rejected at the gateway and never reach the service. The control that matters for DORA Article 9 is that every externally reachable route carries an authentication plugin, and the reader should verify this with a route inventory rather than assume it from the gateway's defaults. Where the openid-connect plugin is used, confirm with your identity provider that the flows and token validation settings match the access model you documented.
The Admin API listens on port 9180 in traditional mode, while client traffic arrives on port 9080, according to the APISIX deployment modes documentation. Port 9180 is the path that can change routes, consumers and plugins, so it must not be reachable from client networks. Restrict it at the network layer with host firewall rules, security groups or network policies that allow only the administrative subnet or the configuration pipeline, and confirm that the Admin API key has been changed from its default value before go-live. Check the same restriction in decoupled and standalone modes, where the configuration source and control plane endpoints differ. Your own network design determines whether the etcd cluster and the control plane sit in the same segment as the data plane, and that placement should be reviewed against the instant severing expectation in Article 9(4).
Segmentation at the gateway can be built from separate APISIX instances, separate deployments per business domain, or separate routes with distinct plugin sets and upstream targets. Separate instances give the strongest blast radius limit, because a compromised data plane cannot reach routes served by another instance, but each instance adds configuration and certificate management. Routes inside one instance share a process and a configuration store, so they are a weaker boundary. Decide which critical or important functions warrant their own instance, and test that a failure or revocation in one segment can be isolated without taking down unrelated services. The exact isolation behavior of your chosen topology is an item to verify in a test environment, not a property to assume from the product.
What APISIX does not cover under DORA
Deploying APISIX covers part of the Article 9 technical controls, but DORA places much of the accountability for the wider ICT framework on the financial entity and its providers. The cards below name the gaps, the article each one touches and the party that owns it, so that the gateway project does not get credited with work it cannot do.
ICT risk management framework
Article 5 and the Chapter II risk management requirements put the ICT risk framework, its governance and management body accountability with the financial entity. APISIX can enforce controls the framework requires, but it does not produce the framework, risk appetite or board reporting. Ask the entity's risk function to confirm which gateway controls map to which framework entries, and keep that mapping under the entity's own document control.
Data classification and risk assessment
Article 9(4)(e) ties encryption strength to data classification and ICT risk assessment. The gateway applies the TLS, mTLS and logging settings it is given, but the entity owns the classification scheme that decides which routes carry which data. Before configuring listeners, confirm with the data owners which APIs carry sensitive or critical-function data, and record that decision in the risk assessment.
Key management policy and HSM decisions
Article 9(4)(e) also requires protection of cryptographic keys. APISIX stores certificates and keys it is configured with, but the key lifecycle, generation ceremony, custody, rotation schedule and hardware security module choice belong to the entity's security team and its key management policy. Ask who approves key rotation and where private keys are generated before any certificate is loaded into the gateway.
Incident classification and reporting
Chapter III sets incident classification and reporting obligations, including timelines and the content of notifications to competent authorities. APISIX can produce access and error logs that feed detection, but it does not classify incidents or decide what is reportable. Confirm which gateway log fields, retention periods and alert thresholds the incident team needs, and whether those logs reach the entity's central monitoring with integrity controls.
Third-party contracts and register
Articles 28 and 30 require a register of ICT contractual arrangements, exit strategies for critical or important functions, and contract terms stating where data is processed and how it is returned. Apache APISIX is open-source software without a contract of its own, but any vendor, support provider or managed service running the gateway falls under these articles. Ask your procurement and legal teams to add each gateway provider, including DeployOpen and any commercial APISIX distribution, to the register.
Patch policy for the platform
Article 9(4)(f) requires documented patch and update policies. Someone must track APISIX releases, the NGINX and etcd dependencies, the Ingress Controller and the plugin set, and decide how quickly each is applied. The project publishes release notes, but the entity owns the schedule, test evidence and approval records. Confirm the supported release line with the project's downloads page before setting a patch window, since the page does not mark any release as long-term support.
Configuration sequence for Article 9 alignment
This sequence turns the Article 9 expectations for the API layer into an ordered build, so each control is chosen from a data classification, implemented in APISIX, kept under change control and left with evidence an auditor can sample. It is a planning sequence, not a statement that any single step makes an entity compliant.
Classify APIs by data sensitivity
Your data owners and risk function list every API route exposed through the gateway, mark the data each one carries and note whether it supports a critical or important function. This classification drives the authentication strength, encryption level and logging depth chosen in later steps, so it needs your own ICT risk assessment as an input. The step closes when each route has a documented classification and an owner who has signed it off.
Select the deployment mode
Choose between traditional, decoupled and standalone deployment, based on where your control plane must run, how configuration is delivered and who can reach the etcd cluster. APISIX documents all three modes, and each changes the attack surface and the recovery design. Confirm the choice with your architecture and security teams against your own environment. The step closes with a written decision record naming the mode and the reasons for it.
Define authentication per route and consumer
For each classified route, select an authentication method from the plugins APISIX provides, such as OpenID Connect against your identity provider, JWT, key-based or client certificate authentication, and document which consumers may call which routes. Strong authentication should be set against relevant standards your authority or auditor accepts, which your own assessment must confirm. The step closes when a test request without valid credentials is rejected on every high-sensitivity route.
Set the TLS policy and certificate lifecycle
Define the protocol versions, cipher policy and certificate authority for client-facing and upstream traffic, then assign owners for issuance, renewal and key rotation. Encryption strength should follow the classification from the first step, so higher-sensitivity routes may need stricter settings or mutual TLS, which your risk assessment must justify. The step closes when a scan of each listener matches the written policy and the certificate inventory lists an owner and expiry date for every entry.
Restrict Admin API and etcd access
Move the Admin API off general network reach, limit it to named administrative hosts and accounts, and restrict direct access to the etcd cluster to the gateway nodes that need it. Protect the stored secrets and keys under the same classification. APISIX documents its default Admin API port, so confirm the port exposure in your own environment before opening any path. The step closes when a connection test from outside the administrative segment fails and the access list is recorded.
Place configuration in version control with approval gates
Store routes, plugin settings, consumers and upstream definitions as files in a version control system, and require a reviewed and approved merge before any change reaches a running gateway. Each change should record who requested it, who tested it, who approved it and the verification result afterwards, which is the documented change management Article 9 describes. The step closes when a test change shows the full trail from request to verification and a rollback is rehearsed.
Test and record network segmentation
Design the gateway's network position so that its upstream connections can be cut or isolated for specific services without taking down unrelated flows, as the second subparagraph of Article 9(4) requires. Test the severing and segmentation paths in a non-production copy and record the results, including what breaks and who is notified. The step closes with a test record that shows each segment can be isolated and restored, and that the isolation was verified.
Define the patch and upgrade policy for APISIX releases
Set the rules for how APISIX gateway and ingress controller releases are assessed, tested, approved and deployed, including emergency patching and the review of plugin changes between versions. Confirm the release support status on the project's download page before you commit to a version, because not every release is marked for long-term support. The step closes with an approved policy and a first upgrade run that is logged through the same change process as configuration.
Choosing a deployment mode for regulated change control
In traditional mode, the data plane and control plane run together on the same nodes, and configuration is stored in etcd. Routes, consumers, plugins and upstreams are written through the Admin API, and each node picks up the change dynamically. The control path is therefore the Admin API plus etcd, and the change record lives in the API calls and in etcd state rather than in a file under version control.
- Admin API placement: The Admin API listens on port 9180 alongside client traffic on port 9080, so it must be bound to a segregated management network and restricted by access control.
- Dynamic changes: Every change is applied live through etcd, which makes rollback and approval gates depend on tooling you add around the API.
- Evidence source: Audit trails come from API logs and your CI or change tickets, not from a repository diff, unless you build that link yourself.
- Node coupling: Gateway nodes hold control logic, so a change to the control path affects every node that reads from the same etcd cluster.
- Access scope: Every person or pipeline with Admin API credentials can alter live routing and authentication, so credential governance carries more weight.
Confirm with your risk assessment whether live API-driven change is acceptable for critical or important functions, and what approval evidence your change process needs before each change is applied.
In decoupled mode, the data plane and control plane run as separate components, and both share one etcd cluster. The control plane serves the Admin API and writes configuration, while data plane nodes read it and handle client traffic. This separates the place where changes are made from the place where traffic is served, which can simplify network segmentation between management and public-facing zones.
- Admin API placement: The Admin API sits on the control plane, so you can keep it in a management segment that data plane nodes reach only for configuration sync.
- Shared etcd dependency: Both planes depend on the same etcd cluster, so its access control, backup and availability become change control concerns.
- Segmentation option: Data plane nodes can sit in a demilitarized or application zone with narrower paths back to the control plane, which supports the segmentation Article 9 expects.
- Change scope: A single control plane change propagates to all connected data plane nodes, so staged rollout depends on how you split environments and nodes.
- Evidence source: Records come from control plane API logs, etcd audit data and your change tickets, and you should confirm which of these your platform retains.
Confirm with your architecture and risk assessment which network paths between planes are permitted and how the shared etcd cluster is documented in your ICT asset inventory.
In standalone mode, APISIX runs without etcd and reads its configuration from a YAML or JSON file, such as conf/apisix.yaml or conf/apisix.json, or through the API. In file-driven operation, APISIX checks the file for changes every second and hot-reloads without a restart. This makes the configuration file itself the control point, which fits naturally with version control, code review and pipeline-based deployment.
- File as control point: The configuration file can be stored in a Git repository with pull request review, signed commits and a tagged release for each approved state.
- Reload behavior: Because APISIX checks the file every second, a change that reaches a node is applied within that window, so deployment gates must run before the file is written to the node.
- Admin API role: Confirm whether you enable the Admin API in standalone mode at all, since the file-driven approach can reduce the attack surface of the management interface.
- Distribution control: Each node holds its own copy of the file, so you must verify that all nodes run the same approved revision.
- Evidence source: Repository history, pipeline logs and file checksums can document what was changed, by whom and when, without an etcd dependency.
Confirm with your risk assessment whether file-based change control meets your requirements for recording, testing, approving and verifying changes, and whether your team has the tooling to detect configuration drift across nodes.
Questions financial entities ask before using APISIX for DORA
Does using Apache APISIX make my organization DORA compliant?
No. APISIX is a gateway that provides controls you can configure to support DORA Article 9 expectations, such as authentication at the API layer, TLS termination, access restrictions and logging. DORA compliance is a property of the whole financial entity: its ICT risk management framework, policies, change management, third-party arrangements and evidence. A gateway contributes to some of those controls but cannot satisfy them alone. Your compliance team should map each Article 9 expectation to the specific APISIX configuration, the process around it and the evidence you keep.
What work is needed to use APISIX for DORA-aligned API security?
The work usually falls into a few parts: confirming which APIs support critical or important functions, choosing the deployment mode, configuring authentication through an identity provider such as Keycloak or Microsoft Entra ID, setting encryption rules by data classification, placing the Admin API on a segregated network, and documenting how gateway configuration changes are recorded, tested, approved and verified. Each part depends on your architecture and risk assessment, so the scope should be agreed in writing before build work starts.
What factors make an APISIX DORA project larger or smaller?
The main effort drivers are the number of APIs and routes in scope, the number of identity integrations and client types, the number of environments and clusters, whether APIs are internal, partner-facing or public, how many data classification levels you apply, and how mature your existing change management tooling is. Routes that carry critical or important functions need more testing and documentation than low-risk internal endpoints. Ask any provider to break the quote down by these drivers so you can see what changes if scope grows.
Can our internal team implement APISIX for DORA without a partner?
Yes, if you have engineers who know NGINX, etcd or Kubernetes, experience with OIDC and TLS, and people who can write and maintain the change management evidence DORA expects. Many teams do the gateway build internally and bring in a partner for specific gaps such as hardening, testing or a documented upgrade path. The main risks in an internal build are uneven documentation, untested configuration changes and unclear ownership of the Admin API and certificates. Assess these honestly against your team's capacity before deciding.
What does DeployOpen deliver in a fixed-scope APISIX engagement?
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers or air-gapped networks. In a fixed-scope engagement, the scope, deliverables and timelines are agreed in writing before work starts. For an APISIX DORA project, the written scope typically defines the APIs covered, the identity integrations, the configuration and change management documentation, the testing performed and the handover. DeployOpen prepares systems, controls and evidence for assessment but does not issue audit reports or attestations.
Does DORA issue a certificate or attestation for an APISIX deployment?
No. DORA sets no certification scheme for ICT systems. Competent authorities supervise compliance using their powers under Article 50. The only authority-issued attestation the Regulation provides for is confirmation that a threat-led penetration test met the requirements under Article 26(7). Any vendor or consultant offering a DORA certificate for a gateway should be questioned closely. Ask your supervisor or internal audit function what evidence they expect, and keep records that let them verify your controls.
How could the Digital Omnibus proposals change DORA scope for APISIX?
The European Commission has proposed a Digital Omnibus package, COM(2025) 837, which could change parts of the digital regulatory framework, including reporting and simplification elements that affect ICT obligations. The procedure is tracked as 2025/0360(COD) in the European Parliament Legislative Observatory. Because the proposals may still change during negotiation, do not assume current requirements will stay the same. Confirm the current status of both documents with your legal and compliance teams before fixing scope, and build your gateway documentation so it can be updated as obligations change.
How should we ask for a written quote for an APISIX DORA engagement?
Send a written request that describes the business context, the APIs and data classes in scope, the identity providers and client types, the deployment targets, the environments, and the evidence you need at the end. Ask the provider to state what is included, what is excluded, which deliverables are produced, what you must supply, the assumptions behind the estimate and how changes to scope are handled. Ask separately which costs are one-time and which recur, such as support or upgrades. DeployOpen provides fixed-scope quotes based on this written scope and does not publish a price list.
What to confirm with your supervisor and auditors
Before any design work starts, confirm how Article 9 applies to your entity. The obligations depend on the type of financial entity under Article 2, the national competent authority that supervises it under Article 46, and whether your organization is also an essential or important entity under NIS2, which affects how DORA interacts with that directive under Article 1(2). A payment institution, an insurer and a credit institution can read the same gateway controls differently, so the first question for your supervisor is which entity category and supervisory route apply to the APISIX gateway and the services behind it.
Then agree the evidence before the build, not after. Ask your supervisor and independent assessors which artifacts they expect for each Article 9(4) item: the Admin API access records, the change records for route and plugin configuration in the change management process, the test results for those changes, and the export format and retention period for gateway and etcd logs. Also ask whether they expect the configuration to be managed as files in version control, since that choice shapes how APISIX is deployed in your environment. Confirm whether the segmentation design, including how the gateway could be severed or isolated quickly, needs a tested runbook as evidence.
Finally, confirm the boundary of what the gateway can prove. APISIX and any supporting service you select will generate the logs and configuration, but the supervisor will judge the whole ICT control set, including identity provider policy and key management outside the gateway. Ask your assessors to review a draft of the scope and the evidence list, and record their answers in writing. This prevents building controls that the supervisor will not accept and missing controls it will ask for.
How DeployOpen scopes and delivers DORA-aligned gateway work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Apache APISIX under DORA ICT security requirements, we turn the Article 9 expectations for the API layer into a written scope, a tested build and handover evidence that your team can keep current.
How we scope
- We confirm which financial services and APIs pass through the gateway and how each is classified for encryption.
- The written scope lists the authentication, TLS, segmentation and change control items to be delivered for your APISIX estate.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build work starts.
How we build
- We deploy APISIX in the mode your architecture needs, then configure identity-backed routes and restricted Admin API access.
- Each gateway change goes through a documented path with a test environment, review and recorded approval before production.
- We test routing, authentication failures, certificate handling and network isolation against the agreed requirements before sign-off.
How we hand over
- You receive configuration as code, runbooks for change, certificate rotation and patching, and the evidence trail the scope defines.
- We walk your engineers through the Admin API controls, plugin inventory and rollback steps so the knowledge stays in your team.
- Evidence is prepared for your own compliance and audit work. DeployOpen does not issue audit reports, attestations or certifications.
How we support
- Ongoing support, version upgrades and continuous testing are available as retainers, scoped separately from the build.
- Retainer work can cover reviewing APISIX releases, such as the 3.19.0 line, against your change and patch policy.
- Before any retainer starts, confirm response expectations, upgrade windows and who approves gateway changes at your organization.
