Apache APISIX and NIS2 cryptography and encryption: what the gateway covers
Yes, APISIX can enforce and evidence the gateway part of an Article 21(2)(h) cryptography policy, but it cannot write the policy or cover the whole estate. Article 21(2)(h) asks in-scope entities to have policies and procedures on the use of cryptography and, where appropriate, encryption. At the gateway, those policies become concrete settings: which TLS protocol versions and cipher suites the listeners accept, which certificates front each route, how upstream connections are verified, and where mutual TLS is required for service traffic. APISIX holds these as configuration you can version, review and export, so the evidence an assessor asks for (what was approved, what is deployed, and when it changed) can be drawn from the gateway itself. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, audits, scans and information requests, so DeployOpen prepares configuration, runbooks and evidence for your own assessment, and it does not certify or attest to compliance.
The gateway covers the parts of the policy that touch its listeners and upstream connections: TLS termination and re-encryption, certificate issuance and renewal workflows, client certificate checks for mTLS and the secrets used to store private keys. The organization-wide policy is not something APISIX can produce. Approved algorithms and key lengths for databases, endpoints, backups and internal tooling sit outside the gateway, and so do key generation, distribution, backup, revocation and destruction for keys that never reach APISIX. National transposition laws also set obligations that a gateway configuration cannot settle on its own. Confirm with counsel or your national competent authority which measures apply to your sector and entity class before scoping the gateway work.
Before the build starts, decide who owns the cryptography policy, which certificate authority issues gateway certificates and where private keys are stored, since those choices shape every later setting. Then confirm in the APISIX version you plan to run how its TLS defaults, Admin API transport and plugin behavior are documented, and record any default you intend to override. Review that record whenever you upgrade, because defaults can change between releases and an approved configuration that was correct last year may no longer match the policy. The APISIX deployment modes documentation is the natural starting point for mapping which ports and interfaces carry traffic in your chosen mode, which in turn determines where TLS must be enforced.
Mapping NIS2 cryptography requirements to APISIX capabilities
This table maps Article 21(2)(h) and the cryptography and key management points of Implementing Regulation 2024/2690 to the APISIX settings that support them, the owner of each control and whether the row is a capability, a partial fit or a gap. Read the status column first: APISIX enforces configured TLS and certificate settings, but the written policy, revocation handling and key lifecycle sit with your organization.
| Requirement | APISIX capability and configuration | Owner | Status |
|---|---|---|---|
| Article 21(2)(h): policy on cryptography and encryption | APISIX enforces the TLS settings you configure but has no policy engine. The approved-algorithm policy document must be written and kept outside the gateway, then mapped to config.yaml and ssl objects. | CISO and security policy owner | Gap |
| Point 9.2(b): approved protocols, algorithms and cipher strength | Set allowed TLS protocol versions and cipher lists in global config or per ssl object. Confirm the exact configuration keys for your APISIX version before relying on them. | Platform engineering | Capability |
| Point 9.2(b): cryptographic agility | Cipher and protocol changes can be made through config-as-code and reloaded without editing routes. Review release notes at each upgrade, because defaults can change between versions. | Platform engineering with security | Partial |
| TLS listener on port 9443 or equivalent | Client HTTPS listener port is set in configuration. 9443 is a common choice, not a fixed default, so confirm the port in your deployment and document it in the policy. | Platform engineering | Capability |
| Certificates through ssl objects | Certificates and private keys are loaded as ssl objects, through the Admin API in traditional mode or in the standalone YAML file. Routes bind to them by hostname (SNI). | Platform engineering | Capability |
| mTLS client verification for service traffic | Client verification is configured on the ssl object with a trusted client CA. Test that untrusted or expired client certificates are rejected before go-live. | Platform and service owners | Capability |
| Point 9.2(c): generation, distribution, storage, changing and activation dates | APISIX loads and rotates keys but does not generate them or track activation and deactivation dates. Use your CA or secrets manager, restrict Admin API access on port 9180 in traditional mode, and record validity dates in your certificate register. | Security operations | Partial |
| Point 9.2(c): compromise and revocation | APISIX does not decide revocation. Revocation checking depends on client and CRL or OCSP setup, and compromise response requires a tested runbook that replaces the affected ssl objects. | Security operations | Gap |
| Point 9.2(c): backup, destruction, logging | Back up etcd in traditional or decoupled mode, or version the YAML or JSON file in standalone mode, which hot-reloads on change. Log Admin API changes and confirm destruction of removed keys in your procedure. | Operations | Partial |
Why the cryptography policy comes before the gateway config
The policy has to exist before anyone edits an APISIX configuration file. Commission Implementing Regulation (EU) 2024/2690 expects the Article 21(2)(h) policy to set the approved protocols, algorithms, cipher strength and usage practices for the entity. The gateway then implements those decisions. If the team opens the ssl_protocols or cipher settings first and decides them there, the organization ends up with an NGINX-era default recorded as its policy, and an auditor will ask who approved it. Before the first certificate is issued in APISIX, the policy should name the minimum TLS version, the permitted cipher suites, the key sizes for certificates and the places where mTLS is required, such as service-to-service traffic inside the cluster. Each of those decisions should then map to a specific APISIX object, such as an SSL resource, an upstream TLS setting or a plugin configuration, so that a reviewer can trace a policy line to a running setting.
Cryptographic agility is the part of the policy that keeps the gateway aligned over time. The regulation refers to following a cryptographic agility approach where appropriate, which in practice means the policy should not hard-code today's algorithms as permanent. It should name review triggers instead: a new APISIX release that changes TLS defaults, an upgrade of the NGINX or OpenSSL base, a new deprecation notice from a standards body, or a change in what the ENISA guidance expects as evidence. Each trigger should have an owner who re-checks the effective settings on a test gateway and records the result. The APISIX release notes and the project's documentation are the first places to check, and the team should confirm with its own build which OpenSSL version ships in the images it runs, since that base determines much of the actual handshake behavior. Those checks belong in the change process, so a version upgrade cannot quietly weaken what the policy approved.
Configuring TLS, certificates and mTLS on APISIX in sequence
This sequence takes the cryptography policy from paper to a running gateway, so each listener, certificate and service route follows approved settings and leaves evidence an assessor can sample. It is ordered so that inventory and policy come before any configuration change, and retesting closes the loop each time APISIX changes.
Inventory every external and internal route
List each route, upstream and listener that the gateway exposes or calls, including client-facing HTTPS endpoints, service-to-service paths, gRPC and WebSocket routes, and any stream or TLS passthrough routes. Record the owner, the data class carried, and whether the route is public, partner-facing or internal. Confirm with the platform team that no route is missing from the list, including routes created directly through the Admin API. The step is done when every route has an owner, a data class and a traffic direction recorded in one register that the security team has reviewed.
Apply the approved protocol and cipher set
Translate the organization's cryptography policy into concrete settings: permitted TLS protocol versions, cipher suites, key sizes and signature algorithms, with the rules for which listeners may use which set. Confirm the exact configuration keys, field names and defaults for your APISIX version in the official documentation rather than relying on memory or older examples. Record the chosen values in the policy and in version-controlled configuration. The step is done when the policy names the approved set and a reviewer has matched each listener to it.
Issue and store certificates and keys
Have the certificate authority or internal PKI issue certificates for each listener and upstream, using the key sizes from the policy. Store private keys in a secrets system that the gateway can read but operators cannot export casually, and keep the APISIX secret-encryption settings enabled where the version supports them. Record issuance, expiry, owner and the renewal method for every certificate. Confirm how revocation and replacement work for compromised keys before go-live. The step is done when a certificate inventory lists each certificate with its expiry date and key location, and a test renewal has been performed in a non-production environment.
Enable TLS on listeners
Configure the gateway's HTTPS listeners with the issued certificates and the approved protocol and cipher set, and disable plain HTTP on routes that carry sensitive data or are required to redirect. Confirm the listener ports for your deployment mode, since the documented defaults differ between traditional and standalone setups. Test each listener with a TLS scanner and with a client that uses only the minimum approved version. The step is done when every listener passes the scan against the policy, and the test output is saved with the change record.
Verify client certificates for service-to-service routes
For routes that only other services should call, require client certificate verification so that the gateway checks the caller's identity during the TLS handshake. Define which certificate authority is trusted for each route group, and map the caller identity to a consumer or upstream policy where your design needs it. Test one accepted call and one rejected call per route group, with the rejected call showing the gateway refused a missing or untrusted certificate. The step is done when both test cases produce the expected results and the trust settings are recorded per route.
Restrict the Admin API and etcd
Limit the Admin API to a dedicated management network, change the default admin key, and restrict access to etcd so that only the gateway nodes and the control plane can reach it. Confirm the default ports for your deployment mode and whether the Admin API can be bound to a separate interface. Where etcd is used, enable its own TLS and client authentication. The step is done when a connection test from outside the management network fails and the etcd access list matches the documented design.
Manage configuration as code under change control
Store the gateway configuration in version control and deploy it through a reviewed pipeline. In standalone or file-driven setups, the gateway reloads the configuration file when it changes, so the file must be protected and its changes approved before they reach production. In decoupled or traditional setups, restrict who can change routes through the Admin API and log each change. The step is done when every production change traces to an approved commit or ticket and the configuration can be restored from version control in a test run.
Retest after each APISIX version change
Before and after every APISIX upgrade or plugin change, rerun the TLS scan, the client certificate tests and the Admin API access check. Read the release notes for changes to default protocols, ciphers or certificate handling, because defaults can move between versions. Track the policy review date so that the cryptography settings are reassessed when the policy or the product changes. The step is done when the retest results for the current version are filed with the change record and any deviation from the policy has an approved exception or a fix.
Evidence an assessor will ask for from the gateway
An assessor reviewing Article 21(2)(h) will want to see what the gateway is configured to do, how that configuration changed over time, and who approved it. The cards below cover the technical records APISIX can produce and the records your organization must still write, so the two sets can be checked against each other.
Versioned gateway configuration in Git
Keep route, SSL and plugin definitions in a Git repository and deploy them through review, so every change to TLS settings has an author, an approver and a timestamp. In standalone or decoupled deployments, the same files serve as the evidence of what was live. Check that the repository history covers the period under review and that direct edits through the Admin API are either blocked or reconciled back into Git.
SSL object exports with protocols and ciphers
Export the SSL objects that terminate client connections and record the allowed protocol versions and cipher lists alongside the date of export. Compare the export against your approved protocol and algorithm list, and flag any object that still permits older protocols or weak suites. Repeat the export after each APISIX upgrade, because default values can change between releases.
Certificate inventory with issue and expiry dates
Maintain an inventory that lists every certificate loaded into the gateway, the hostnames it covers, its issuer, its issue date, its expiry date and the owner responsible for renewal. Reconcile the inventory against the SSL objects in APISIX so no certificate is served without a record. Ask your certificate authority or PKI team to confirm which certificates they issued and which were self-signed.
Key rotation and revocation records
Record each private key rotation, the reason for it, the date the old key was retired, and where the replacement key is stored. Include revocation requests and the steps taken when a key is suspected compromised. Your key management procedure must define these events, and the gateway record must show that they happened. The procedure and its approval are your documents, not something APISIX produces.
mTLS client policy
Document which upstream services and clients must present a certificate, which certificate authority signs them, and how client identities map to gateway consumers or routes. Export the TLS client settings for each protected route and compare them with the policy. Test with a client that has no certificate and with an expired one, and keep the results, since an assessor will ask for proof that the control rejects them.
Gateway access logs showing TLS version
Configure access logs to record the TLS protocol version and cipher for each connection, then retain them under your logging policy. Sample entries for connections that used older protocols and confirm that none were accepted after the cutoff in your policy. Logs must not carry request payloads or personal data, and their storage and access controls should be covered in the same evidence pack.
What the gateway does not cover for NIS2 cryptography
APISIX terminates and enforces TLS at the edge, but Article 21(2)(h) reaches the whole entity. The cards below mark the cryptography work that sits outside the gateway, who owns each item, and where DeployOpen can help prepare the material your team and assessors will ask for.
Entity-level cryptography policy and approval
The gateway configuration implements a policy; it does not define one. Implementing Regulation 2024/2690 expects a documented policy that sets approved protocols, algorithms, cipher strength and usage practices across the organization, with a cryptographic agility approach where appropriate. Your leadership must approve that policy, assign an owner and review it when APISIX defaults or your risk picture change. DeployOpen can help draft the gateway section and map it to your existing policy set.
Key management for backend systems
APISIX can store and reference certificates and keys, but the lifecycle of keys used by applications, databases, message brokers and internal services sits with those systems and their owners. Point 9.2(c) of the Implementing Regulation covers generation, distribution, storage, rotation, compromise, revocation, recovery, backup, destruction and activation dates. Confirm which team owns each key, where it is logged and how revocation reaches every consumer.
Backend TLS not terminated at APISIX
When APISIX proxies to upstream services, the connection from the gateway to each backend is a separate encrypted hop. Any segment that terminates TLS elsewhere, such as a load balancer, a service mesh sidecar or a legacy application, needs its own protocol and cipher review. Map every hop in your architecture diagram, record which component negotiates which TLS version, and confirm that mTLS to services is enforced where your policy requires it.
Certificate authority operations
Someone must issue, track and revoke the certificates APISIX presents to clients and uses for mTLS. The gateway does not operate a certificate authority. Decide whether you run an internal CA, use a managed CA or a public issuer for edge certificates, and document issuance approvals, renewal alerts, revocation procedures and the audit trail. Confirm how CRL or OCSP responses are served to your consumers before you rely on them.
Hardware and HSM choices
Whether private keys must sit in a hardware security module, and which certification level applies, depends on your risk assessment and national requirements, not on the gateway. APISIX can read keys from supported secret managers, but the choice of HSM, its tamper protection and its backup model are decisions for your security architects. Ask your vendors which key stores they support and confirm the requirement with your national competent authority before design begins.
National transposition and supervision details
NIS2 is a directive, so obligations reach your entity through national law, and supervision differs by Member State and by essential or important status. Member States may also adopt stricter rules under Article 5. No NIS2 certificate exists: competent authorities use inspections, audits, scans and information requests. Confirm your national transposition law, your supervisory authority and any sector guidance, then ask legal counsel how that evidence will be requested.
What does NIS2 cryptography work on APISIX cost and require?
What drives the effort of NIS2 cryptography work on APISIX?
The main drivers are the number of routes and upstream services, how many legacy clients still negotiate older TLS versions or ciphers, how far mTLS extends into internal service traffic, and how mature your existing PKI is. Each route that needs a documented protocol and cipher decision adds review work, and each legacy client that must be supported can force a compromise that has to be recorded and time-limited. Internal mTLS scope usually matters most, because it touches certificate issuance, rotation and trust stores across teams. A mature internal CA with defined certificate profiles shortens the work considerably. Ask for the effort breakdown by these drivers in the written scope.
Can our own team implement NIS2 cryptography controls on APISIX in-house?
Many teams can do parts of it in-house, particularly if they already run APISIX or NGINX-based gateways and have a working PKI. The harder parts are usually the policy itself, the key lifecycle procedures covering generation, rotation, revocation, backup, destruction and logging, and the evidence trail that shows those procedures operate. Gaps tend to appear in periodic review of the cryptography policy as APISIX defaults change between releases, and in consistent configuration across environments. Assess your team against the work the policy requires, and decide which parts you keep and which you hand to a partner. DeployOpen can plan, implement and document the work in your infrastructure under a fixed scope.
What does the work require from our team to complete it?
The work needs named owners from several groups. Policy owners, usually security or compliance leads, must approve the protocols, algorithms, cipher strength and usage practices the policy sets. PKI staff must confirm certificate authorities, certificate profiles, issuance and revocation processes, and key storage. Network staff must confirm which listeners, upstreams and internal paths carry traffic and which clients can be upgraded. Platform or application teams must test legacy client behavior and schedule changes. Engineers also need access to the APISIX Admin API, the configuration repository and the environments where changes are tested. Agree these roles and availability in the written plan before work starts.
How long does NIS2 cryptography work on APISIX take?
Duration depends on the scope described above, including route count, client compatibility testing, the state of your PKI and how many environments are involved. No general duration applies, and any figure you see without a written scope should be treated with caution. DeployOpen sets the timeline in the written plan for each engagement, with deliverables and milestones agreed before work starts. Ask for the phases, the dependencies on your teams and the points where client testing or certificate changes can delay the schedule.
What is a quote for APISIX cryptography work based on?
A quote follows from the written scope. It should list the routes and services in scope, the environments covered, whether internal mTLS is included, the state of the existing PKI, the number of legacy clients that need a documented exception, and the evidence the policy requires. Costs fall into one-time work such as design, configuration, testing and documentation, and recurring work such as policy review, certificate operations and gateway upgrades. Ask the provider to separate these, to state who is responsible for each deliverable, and to list what is excluded. DeployOpen does not publish a price list.
Does running APISIX make us NIS2 compliant?
No. NIS2 creates no certificate of compliance, and the platform alone does not satisfy Article 21(2)(h). The gateway provides the enforcement point for TLS and mTLS settings, but the obligation covers a policy and procedures for cryptography and, where appropriate, encryption, plus key management processes and evidence that they operate. National competent authorities oversee compliance through inspections, audits and information requests, so the evidence matters as much as the configuration. Confirm with your legal and compliance advisers how your national transposition law applies to your entity. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports or certifications.
What should we ask a provider before accepting a NIS2 cryptography scope?
Ask how the scope covers the cryptography policy, key lifecycle procedures, gateway TLS and cipher configuration, mTLS for service traffic and the review process when APISIX defaults change. Ask which evidence the provider will produce, such as configuration exports, certificate inventories, test results and change records, and who keeps that evidence current. Ask how legacy client exceptions are documented and retired. Confirm which items are excluded, including PKI redesign, client application changes and ongoing monitoring. Finally, ask for the acceptance criteria in writing so you can verify delivery against them.
Reviewing the cryptography policy as APISIX defaults change
Treat every APISIX and APISIX Ingress Controller release as a trigger for reviewing the cryptography policy, because the approved protocols, cipher settings and certificate handling you documented for Article 21(2)(h) were only true for the version you tested. The downloads page lists APISIX 3.19.0, released on September 28, 2026, and APISIX Ingress Controller 2.2.0, released on August 18, 2026, as examples of the kind of change to check. Those releases are not marked as long-term support, so your review cadence should follow your own upgrade plan rather than assume a stable baseline. Confirm the project's release and support plan directly with the Apache APISIX project before you commit to a schedule, since the page does not state one.
For each release, diff the rendered configuration before and after the upgrade, not only the files you edited. Compare the TLS-related fields on your SSL objects, the admin and gateway listener settings, the ssl_protocols and ssl_ciphers values in your config.yaml, and any mTLS client certificate settings on routes and upstreams. In standalone mode, compare the apisix.yaml or apisix.json file that APISIX reloads, and in traditional or decoupled mode, export the relevant resources through the Admin API on port 9180 and diff those exports. Record the results as change evidence, because a changed default that nobody noticed is exactly the gap an assessor will ask about.
After every upgrade, rerun external and internal TLS scans against the gateway listeners and the mTLS upstream paths, and compare the results with your last accepted baseline. Check protocol versions, cipher suites, certificate chains and expiry dates, and confirm that deprecated options are still rejected. Where a scan shows a change, decide whether the cryptography policy needs an update, a configuration fix, or a documented exception with an owner and a date. Keep the scan reports, the diffs and the sign-off together so the review trail shows that the policy was checked against the running version.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Apache APISIX and NIS2 cryptography and encryption, we turn the gateway's TLS, certificate and mTLS settings into a written, testable cryptography configuration that your team can own and review as APISIX defaults change.
How we scope
- Inventory every external and internal route the gateway terminates, re-encrypts or passes through, with its current protocol and cipher settings.
- Agree in writing which approved protocols, cipher suites and key lengths apply to each route class, based on your cryptography policy.
- Define the certificate authority, key generation, renewal, revocation and backup responsibilities that the scope will cover.
How we build
- Configure TLS policies, certificate sources and mTLS for service traffic in the deployment mode your architecture uses, under configuration as code.
- Test the negotiated protocols and ciphers against the written policy from outside the gateway, and record the results as evidence.
- Lock down the Admin API and stored secrets so that changes to cryptography settings are authenticated and logged.
How we hand over
- Deliver a cryptography standard document mapping each setting to the policy clause it satisfies, with the reasoning for each choice.
- Provide a key and certificate register with owners, activation and deactivation dates, and the procedure for compromise and destruction.
- Train your operators to review APISIX release notes and default changes, and to re-run the test suite before any upgrade.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing of the gateway's cryptography configuration are available as a retainer.
- Ask for a written quote based on your scope; DeployOpen does not publish a price list.
