API management for the public sector

Why API management for the public sector needs a different starting point

For most agencies, the first decision is not which gateway product to buy but which traffic it carries. X-Road fits inter-organization data exchange, where one authority needs to query another authority's records under a secure, auditable trust model. A general gateway such as Apache APISIX or Kong fits citizen-facing services and open data APIs, where the consumers are applications, developers and the public rather than member organizations. Many agencies end up running both: X-Road as the exchange layer between organizations, and a general gateway in front of the services that citizens and open data users call. Mapping each existing API to one of those two patterns is the first task in any public sector gateway project.

Hosting location and the applicable security baseline then shape the choice more than feature lists do. Under the FBI CJIS Security Policy, version 6.1 requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for criminal justice information in transit and at rest outside physically secure locations, so the gateway's TLS and key handling must be verified against that text. For federal cloud use, FedRAMP scope depends on whether a cloud service is offered as a shared service, which makes the hosting model a compliance question as well as an operations one. Confirm with your assessor which baseline and which control catalog applies (NIST SP 800-53 Rev. 5 baselines differ in control count) before you choose where the gateway and its etcd or PostgreSQL state will run.

Which public sector requirements shape the gateway build

This table maps the public sector requirements most likely to apply to a government API gateway to the concrete build decisions they affect. Read each row as a question to answer with your legal, security and procurement teams before the gateway design is fixed, since applicability depends on your jurisdiction, data classes and hosting model.

Requirement	What it means for the gateway	Evidence an assessor will ask for
NIST SP 800-53 baselines and FISMA	Federal agencies select a low, moderate or high baseline (149, 287 or 370 controls and enhancements respectively). The chosen baseline sets how strictly the gateway must log administrative access, control configuration changes and restrict the Admin API.	Baseline selection record, system security plan entries mapped to the gateway, and configuration baselines for the gateway nodes and etcd
FedRAMP scope for cloud-hosted services	If a cloud-hosted gateway or managed control plane creates, stores or processes federal information for an agency as a shared service, FedRAMP applies. A single-agency system on cloud infrastructure that is not offered as a shared service may be out of scope, so confirm the classification early.	Scope determination, provider authorization status for each cloud service in the path, and a boundary diagram showing where traffic and logs reside
CJIS Security Policy v6.1 encryption and scanning	Criminal justice information in transit and at rest outside physically secure locations needs FIPS 140-3 validated modules or AES with at least 256-bit keys. Vulnerability scanning of gateway hosts and plugins must run at least monthly. Confirm TLS termination points and certificate key sizes on every route.	Cryptographic module certificates, TLS configuration exports, monthly scan reports and the CJIS requirements companion document mapping
32 CFR 2002.14(h)(2) and CUI on non-federal systems	Federal agencies applying NIST SP 800-171 to non-federal systems that handle controlled unclassified information require the gateway operator and its hosting to meet those safeguards unless the CUI category sets other rules. Developer portals and partner access paths carry the same obligation when they handle CUI.	Documented safeguard mapping to SP 800-171 requirements, access control records for partner keys, and audit logs of API access to CUI routes
ADA Title II WCAG 2.1 dates	State and local entities must meet WCAG 2.1 Level A and AA for web content and mobile apps, including content delivered through contracts. The dates are 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. Citizen-facing API status pages, key request forms and developer portals fall under this duty.	Accessibility conformance report for each front end, remediation plan with owners, and a statement of which portal pages the agency controls
NIS2 scope for public administration	NIS2 covers central government entities of any size and lists public administration as a sector of high criticality, with member states able to extend it to local administration. Gateways supporting such entities need incident reporting, supply chain security and logging suited to those duties. National security, defense and law enforcement entities are excluded.	Scope confirmation from the national transposition, incident response runbook covering gateway outages, and supplier security records for open-source components and the implementation partner

Where X-Road fits versus a general API gateway

X-Road is open-source software and an ecosystem for unified, secure data exchange between organizations. Its design centers on trust between member organizations rather than on a single owner's public endpoint. Each organization runs its own Security Server, and the Central Server and Configuration Proxy hold the shared trust and configuration that members rely on. Public sector agencies often use this model when they need to exchange records with each other under agreed rules, with every exchange traceable to a named member.

Member trust model: Organizations are onboarded as members with certificates issued under the ecosystem's rules, so both sides of a call are identifiable.
Component roles: The Central Server, Security Server and Configuration Proxy each have a defined job, and the installation guide describes their supported platforms (Ubuntu, RHEL and Docker).
Hardware key support: X-Road supports hardware security modules through PKCS#11 drivers with RSA and EC keys, which matters where key custody is a policy requirement.
Operational footprint: The Security Server needs PostgreSQL, local or remote, and a minimum of 3 GB RAM and 3 GB free disk space, so plan the database and host sizing early.
Licensing: X-Road is published under the MIT license and developed by the Nordic Institute for Interoperability Solutions.

Confirm with the agencies involved whether their legal framework already names X-Road or requires a specific exchange model before you select it.

Which open source gateways fit public sector API work

Public sector API work usually splits into two layers: a gateway that enforces authentication, traffic limits and observability for citizen and agency APIs, and an exchange layer that moves data between agencies under legal trust rules. The cards below cover the components that most often appear in these designs and the checks to run before choosing one.

Apache APISIX as the gateway

Apache APISIX is licensed under Apache-2.0 and is currently at version 3.19.0. It runs in traditional mode, decoupled mode with a shared etcd cluster, or file-driven standalone mode, where configuration lives in a YAML or JSON file that the gateway reloads on change. Standalone mode suits air-gapped or tightly change-controlled environments, but it moves configuration governance into your Git and release process. Confirm which mode your operations team can run and who approves configuration changes.

Kong Gateway as the alternative

Kong Gateway is licensed under Apache-2.0 and is currently at version 3.9.4. It is a reasonable comparison candidate where your teams already run Kong, or where a broader plugin catalog and a familiar administration model matter more than the APISIX deployment options. Compare the plugins you need for citizen authentication, rate limits and logging against each product's documentation, and confirm which features in your target edition are open source and which require a commercial license.

OpenID Connect for citizen identity

The APISIX openid-connect plugin can validate tokens and run authorization code, client credentials, introspection and PKCE flows against identity providers such as Keycloak, Microsoft Entra ID, Okta and Auth0. This lets the gateway enforce who may call an API without embedding login logic in each service. Check whether your citizen identity source issues tokens that the plugin can validate, and where scopes and claims for agency roles are mapped.

Keycloak as an identity broker

Keycloak is useful where national eID schemes, agency directories and partner identity providers must be brokered into one token issuer that the gateway trusts. It sits between the national identity source and the APIs, so the gateway validates one issuer rather than many. Confirm which eID schemes you must accept, whether a national scheme requires a certified integration, and who operates the broker under the agency's security policy.

X-Road Security Server for agency exchange

X-Road is open-source software under the MIT license for secure data exchange between organizations. Its Security Server handles message exchange with trust anchors, certificates and service registration, which a general gateway does not provide on its own. Use X-Road where agencies must exchange data under a shared trust framework. Confirm the operating system, PostgreSQL service and HSM requirements, and whether your deployment can accept the Security Server's external ports.

Choosing by identity and traffic profile

The right fit depends on your identity and traffic profile, not on a product ranking. Map which callers are citizens, agency systems or partners, which identity sources they use, and whether traffic is inter-agency exchange or public access with rate limits. Use a general gateway for public or citizen-facing APIs, X-Road for trusted agency-to-agency exchange, and both where each layer solves a different problem. Confirm this mapping with your identity team and architecture board before selecting a platform.

Deployment patterns for sovereign and air-gapped hosting

A public sector X-Road and gateway estate is only as sovereign as its weakest hosting decision. The cards below cover where data, control planes, databases and keys sit, and which network paths must be opened and which must stay closed. Each item is a decision the agency makes before procurement, not after go-live.

In-country data center deployment

Place the Security Server, the gateway data plane and any logging stack in data centers located in the jurisdiction whose rules apply to the service. Confirm with legal counsel whether the sovereignty requirement covers only stored data or also administrative access, backups and support sessions. Ask the implementation partner to document every location that holds message payloads, logs or configuration, including disaster recovery sites.

Separate open data tier

Keep open data APIs on a gateway instance or route group that is separate from internal agency-to-agency exchange. Open data traffic is public, high volume and rate limited, while X-Road exchange is authenticated between known members. Separating the tiers limits the blast radius of a traffic spike or a misconfigured public route, and it keeps each tier's logs and retention rules distinct.

Control plane inside the agency network

For APISIX, the traditional and decoupled modes place the Admin API and etcd cluster under the agency's control, while standalone mode loads configuration from a file that can be versioned in Git and reviewed before deployment. Decide which mode fits the agency's change control and whether the control plane may run outside the data plane's network zone. Confirm that the Admin API on port 9180 is reachable only from management networks.

Security Server network ports

The Security Server accepts TCP 5500 for message exchange and TCP 5577 for OCSP from external networks, which must be open to other X-Road members. TCP 4000 for the admin UI and TCP 8080 or 8443 for information system access belong on internal networks only. Write these as firewall rules with named source zones, and have the partner show that the admin port is not reachable from the internet or from member networks.

PostgreSQL placement

The Security Server requires PostgreSQL, either local or remote. Decide whether the database runs on the same host, on a dedicated database host in the agency network, or on a managed service. A local database simplifies the boundary but couples backups and patching to the Security Server, while a remote database needs encrypted connections and its own access controls. Ask for the backup, restore and failover procedure as a tested runbook.

HSM keys through PKCS#11

X-Road supports hardware security modules through PKCS#11 drivers using the xroad-addon-hwtokens package, with RSA and EC keys. Keeping signing and authentication keys in an HSM inside the agency's facility means that key material never leaves hardware the agency controls. Confirm the HSM model is on the partner's tested list, plan key ceremonies and backup, and check the vendor's certification status with the HSM supplier.

Managed database services and sovereignty

The X-Road Security Server documentation lists managed PostgreSQL services such as AWS RDS and Azure Database for PostgreSQL as supported remote options. Whether these are permitted depends on the agency's sovereignty rules, which may restrict where the provider's staff, backups and control plane operate. Check the provider's region, support access model and key management before choosing a managed option, and record the decision in the architecture file.

How citizen identity and open data rate limits change the design

The gateway is the first place a citizen token should be checked, and the design decision is what it verifies there. For authenticated citizen APIs, the gateway validates the token against the identity provider before traffic reaches the agency service. The APISIX openid-connect plugin supports authorization code, client credentials, token introspection and PKCE flows with identity providers such as Keycloak, Auth0, Microsoft Entra ID, Google and Okta. Confirm with your national eID or citizen identity scheme operator which identity provider, token format and claims are authoritative, whether the scheme supports the flows you need, and how token revocation is communicated. Signature and audience checks at the gateway reduce load on back ends, but object-level decisions, such as whether one citizen may read another citizen's record, remain with the service.

Anonymous open data APIs need a different design, and treating them as a subset of citizen APIs usually causes trouble. Here the gateway identifies the consumer class instead of the person, for example by API key, by a registered application, or by the client address where keys are not practical. Separate rate limits per consumer class let authenticated citizen and agency traffic keep a predictable allocation while anonymous reuse of published datasets stays available. Set the actual limits from measured traffic over a representative period, not from a vendor example or a number copied from another administration. Review them with the owners of the datasets, because a bulk export job and an interactive portal can produce very different request patterns from the same consumer.

Citizen-facing web and mobile front ends that sit on these APIs carry their own compliance dates. The ADA Title II rule requires state and local government web content and mobile apps, including those provided through contracts or licenses, to meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts. Ask your legal team which category applies to each service, and ask the front-end team to confirm that the APIs they call return the data needed for accessible output. The gateway itself does not make content accessible, but its error responses and rate-limit messages are part of what users with assistive technology encounter, so include them in testing.

How a public sector gateway rollout runs in phases

The sequence moves from classifying APIs and data to run-state operations, so each agency's traffic reaches the gateway only after the hosting, identity, logging and scanning evidence it needs is in place. Each phase closes with a written artifact that a security lead, an agency owner or an assessor can review.

Classify APIs and data by sensitivity
The team inventories every API in scope, the agency that owns it, the consumers, and the data each call returns or accepts. Records containing criminal justice information or controlled unclassified information are marked explicitly, along with any personal data and any open data meant for public reuse. Agency owners sign the inventory. The phase closes with a classified API register that drives every later decision about hosting, authentication and rate limits.
Confirm the control baseline and hosting constraints
Using the classification, the team identifies which control baseline applies, such as a NIST SP 800-53 low, moderate or high profile, and which laws or agency policies add requirements. It also confirms where data may be processed, whether a cloud provider needs FedRAMP authorization for the workload, and which networks, accounts or data centers are permitted. Agency security and legal staff confirm these constraints in writing. The output is a baseline and hosting constraint memo that every later phase must satisfy.
Select the exchange and gateway split
The team decides which traffic belongs on X-Road, which suits authenticated data exchange between government organizations, and which belongs on a general gateway such as Apache APISIX or Kong Gateway, which suits citizen-facing, partner or open data APIs. Deployment mode, control plane location and the components for each path are chosen against the constraints from the previous phase. The output is an approved architecture decision record that names each component, its hosting location and the reason for the choice.
Build identity and rate limit integration in non-production
In a non-production environment, the team connects the gateway to the agreed identity provider for citizen or agency login, configures token validation and scopes, and sets rate limits per consumer class, such as higher limits for an agency system and stricter limits for anonymous open data callers. Accessibility and error handling requirements for any web front ends are tested alongside. Testers confirm that denied and throttled requests are logged. The output is a tested integration build with test results and a list of open defects that must close before cutover.
Complete logging and vulnerability scanning evidence
The team turns on access and audit logging with retention, integrity protection and export to the agency's security monitoring, and it schedules vulnerability scanning for the gateway, the X-Road Security Server where used, and the backing databases at the frequency the baseline requires. Cryptographic settings are checked against the baseline, including approved modules and key lengths where criminal justice information is involved. The output is a control mapping that links each applicable control to the configuration, the log sample and the scan report that evidence it.
Run controlled cutover for each agency
Agencies move to the gateway one at a time, starting with a limited set of routes and consumers. Each cutover uses a written rollback plan, a freeze window agreed with the agency, and a check that traffic, logs and authentication behave as the test results predicted. Routes are not moved in bulk until the first agency has run a full cycle without material defects. The output is a signed cutover record per agency and an updated API register showing where each route now runs.
Operate, patch and test failover in run state
After cutover, the team operates the gateway under a documented runbook covering configuration changes kept in version control, upgrades, certificate and key rotation, log review and periodic scanning. Failover is exercised on a schedule that the agencies agree, and the results are recorded. Support responsibilities are split between the operator, the agency and any X-Road membership obligations. The output is a tested failover runbook, a current control mapping and a quarterly operations report that the agencies and assessors can read.

Evidence assessors ask for from the gateway and exchange layer

This table maps the evidence an assessor typically asks for to the component that produces it, from gateway configuration and logs to HSM records and scan results. Use it to plan which artifacts each team owns before an assessment begins. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any audit reports or certifications.

Evidence	Source component	What the assessor checks	Confirm before assessment
Gateway configuration history	APISIX or Kong configuration kept in Git	Who changed routes, plugins and auth settings, when, and under which approval	Whether the deployment mode and config sync path are documented and reviewed
Access and audit logs	APISIX access logs and X-Road Security Server logs	Who called which service, from where, and whether logs are complete and tamper-resistant	Log retention period set by your agency policy and the applicable baseline, and where logs are forwarded
X-Road message and certificate records	X-Road Central Server and Security Server	Which member and service consumers exchanged data, and whether certificates were valid at the time	Whether OCSP responses and certificate renewal records are retained alongside logs
TLS and key management records	Gateway TLS termination, X-Road signing and authentication keys	Certificate inventory, key lengths, rotation dates and who holds key custody	Whether cryptographic modules meet the FIPS requirements in your applicable CJIS or agency policy
HSM configuration	PKCS#11 hardware token setup for X-Road keys	Token inventory, access controls, backup and key ceremony records	Whether your HSM is validated to the standard your agency or contract requires
Vulnerability scan results	Scanning of gateway hosts, X-Road Security Servers and the database	Scan cadence, findings triage, and closure records against the scanning frequency in your policy	Scan frequency required by the CJIS Security Policy version in force for your data
Rate limit and authentication test results	Test reports for OIDC, API key and rate limit plugins	Evidence that throttling and token checks block unauthorized or excessive requests	Test scope covers citizen identity flows and open data endpoints, not only the happy path
Control mapping to the NIST baseline	Control matrix mapping components to SP 800-53 control IDs	Which controls the gateway and exchange layer implement, inherit or leave to the agency	Chosen baseline (low, moderate or high) and the matching OSCAL profile from NIST

What public sector teams ask before building a gateway

Is X-Road required for government data exchange between agencies?

No single rule makes X-Road mandatory, so the answer depends on the data exchange model your agency or country has adopted. X-Road is open-source software and an ecosystem for unified, secure data exchange between organizations, published under the MIT license, and it is designed for trusted, identified exchange between organizations. A general API gateway such as Apache APISIX handles client-facing traffic, authentication and rate limits well, but it does not provide the organization-to-organization trust framework that X-Road offers. Confirm with your national interoperability authority and your legal team which exchange model applies, then decide which layer each flow uses. Many agencies run both: X-Road for cross-agency exchange and a general gateway for citizen and partner APIs.

What drives the cost of an agency API gateway build?

The main cost drivers are the number of APIs and consuming systems, the identity integration, the depth of security and audit requirements, and how many environments must be run and documented. Software licensing is not the main driver for Apache APISIX or Kong Gateway, both licensed under Apache-2.0, but infrastructure, hardening, testing, and operations are. Costs fall into one-time work (architecture, integration, hardening, migration and documentation) and recurring work (patching, upgrades, monitoring and support). If you are using X-Road, add the Security Server hosting and the PostgreSQL service it requires. Ask any integrator for a written scope that lists the APIs, identity providers, environments, and compliance evidence included, since that scope determines the quote.

How long does a public sector API gateway project usually take?

Duration depends on scope, not on a fixed template, so no general timeline applies. The factors that lengthen projects are unclear API ownership, an identity provider that needs integration or change, procurement and security approvals, the number of environments, and whether a hardware security module or sovereign hosting is required. Simple, single-agency gateways with a clear API inventory move faster than multi-agency exchanges that must agree on trust frameworks and certificates. Ask for a timeline tied to named milestones such as architecture sign-off, pilot APIs, security testing and production cutover, and ask which of those depend on your own approvals.

Can an agency team run a self-hosted API gateway without outside help?

Yes, an in-house team can run a self-hosted gateway if it has skills in Linux operations, TLS and certificate management, identity protocols, and infrastructure as code. APISIX supports traditional, decoupled and standalone deployment modes, and the standalone mode reads configuration from a YAML or JSON file, which keeps the setup simpler for small teams. The harder parts are ongoing: patching, upgrades, plugin changes, incident response and audit evidence. Assess your team against those tasks before deciding. Many agencies keep day-to-day operations in-house and use an implementation partner for the initial build, hardening and documentation, which DeployOpen offers as fixed-scope work or as a retainer for ongoing support.

Does FedRAMP apply to a self-hosted API gateway?

FedRAMP applies to cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. Under the scope set by OMB memo M-24-15, systems used only for a single agency's operations on cloud infrastructure, and not offered as a shared service, are out of scope. A gateway that your agency runs in its own cloud account for its own APIs may therefore fall outside FedRAMP, but a shared gateway service offered to several agencies by a provider could fall within it. Confirm the classification with your authorizing official or FedRAMP counsel before you design the architecture. The NIST SP 800-53 control catalog still shapes what the system must document, whichever the classification.

How does the X-Road 7 to X-Road 8 transition affect planning?

Plan for X-Road 7 now and track X-Road 8 as a future migration. The current release is 7.8.3, with supported versions 7.8.3, 7.7.4 and 7.6.5. X-Road 7.8.0, released at the beginning of February 2026, is the last new-feature release of X-Road 7. NIIS intends to maintain X-Road 7 with bug fixes and security patches beyond 2026, but the length of that period has not been decided. X-Road 8 "Spaceship" is available for testing as 8.0.0 Beta 2, with production release scheduled for December 2026. Do not assume a migration date. Ask your integrator to design Security Server deployments so configuration, certificates and HSM keys can be moved, and to document an exit path before committing to a production design.

What infrastructure does an X-Road Security Server need?

The Security Server runs on Ubuntu Server 22.04 or 24.04 LTS on x86-64, or on Red Hat Enterprise Linux 8 or 9. The minimum is 3 GB RAM, rising to 4 GB with monitoring add-ons, plus 3 GB of free disk space. It requires PostgreSQL, which can be local or remote, including managed services such as AWS RDS and Azure Database for PostgreSQL. It accepts TCP 5500 and 5577 from external networks and uses TCP 4000 for the admin UI and 8080 or 8443 from internal networks. Hardware security modules are supported through PKCS#11 drivers with the xroad-addon-hwtokens package, for RSA and EC keys. Confirm these requirements against your current installation guide before sizing hardware.

Questions to ask an implementation partner for a public sector gateway

Start with X-Road experience, because it decides how much of the gateway work is new. Ask the partner which X-Road releases they have deployed in production, and whether they have moved a Security Server from one supported line to another. The supported versions today are 7.8.3, 7.7.4 and 7.6.5, and NIIS has said 7.8.0 is the last new-feature release of the X-Road 7 line, with the length of the maintenance period not yet decided. Ask for their plan for X-Road 8, which is in beta and has a production release scheduled for December 2026, and whether they will commit to upgrade work or only to an initial installation. Confirm the Security Server hosting model too: the supported operating systems, the PostgreSQL service (local or managed) and how PKCS#11 hardware tokens are configured through the hwtokens add-on.

Next, ask how controls are mapped to the applicable baseline before any configuration is written. The answer should name the baseline your agency is assessed against, such as the moderate or high baselines in NIST SP 800-53B, and show a control-by-control trace from gateway settings (TLS policy, access logs, admin access, rate limits) to the evidence an assessor will request. Ask who owns each mapping row and how it is kept current when the catalog changes. For criminal justice information, ask how the partner separates CJI from other traffic, which encryption modules they use for CJI in transit and at rest, and how monthly vulnerability scanning is scheduled against the gateway and its host. For CUI, ask how the boundary is drawn, and whether the partner has tested data paths against the requirements of NIST SP 800-171.

Finally, ask how identity brokering is tested and how configuration is governed. Request a test plan for the openid-connect flows your agencies will use, covering authorization code with PKCE, client credentials and token introspection, along with negative tests for expired tokens, wrong audiences and revoked sessions. Ask how they keep routes and plugin settings in Git, who approves changes, and how a gateway upgrade is staged across agencies, including canary routes, rollback steps and how partner-facing APIs are kept stable. Ask directly whether the design works in air-gapped operation, including offline package mirrors, certificate authority handling and time synchronization. Ask for a written answer on each point, and treat a vague one as a finding.