How Apache APISIX supports HIPAA transmission security for ePHI APIs
If your organization is a covered entity or business associate and exposes or consumes electronic protected health information through APIs, you need evidence for two technical safeguards: transmission security under 45 CFR 164.312(e)(1) and audit controls under 164.312(b). An Apache APISIX gateway can supply much of the technical evidence for both at the API boundary. It terminates TLS for client traffic, can enforce TLS or mTLS toward upstream services, restricts which consumers reach which routes, and records API access in logs you control. It does not satisfy the rest of the Security Rule. The gateway cannot perform your risk analysis, write your policies, train your workforce, manage business associate contracts under 164.314, or decide which data elements count as ePHI in your systems. Those remain organizational work, and an assessor will ask for them alongside the gateway configuration.
Plan the evidence before the build. For transmission security, the reader should be able to show which listeners accept ePHI traffic, which TLS versions and cipher suites are permitted, how client certificates are issued and rotated, and how upstream connections to ePHI services are secured. For audit controls, the reader should decide which access records the gateway writes, where they are stored, how long they are kept, and who reviews them. Confirm with your security team which of these HIPAA requirements your risk analysis already treats as addressable under 164.306(d), because the answer determines whether an equivalent alternative must be documented. Also confirm the exact TLS and logging behavior of the APISIX release you plan to run, since defaults and plugin options change between versions.
There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, and that private certifications do not stop HHS from later finding a violation, so any vendor or partner claiming to certify HIPAA compliance for a gateway is making a claim HHS does not recognize. DeployOpen configures, documents and collects evidence for the gateway controls described here and prepares that evidence for review. It does not issue audit reports, attestations or certifications, and it cannot make your organization compliant on its own. Independent assessment and your own governance records remain necessary, and the HHS Security Rule guidance is the natural starting point for mapping them.
Mapping HIPAA technical safeguards to APISIX capabilities and configuration
This table maps each HIPAA technical safeguard that applies to API traffic carrying ePHI to the APISIX feature that usually supports it, and to the configuration decision you must make. Read each row as a starting point for your risk analysis: the gateway supplies the control, but the evidence depends on how your team configures and records it in your APISIX version.
| Safeguard or specification | APISIX capability to confirm | Configuration and evidence to keep |
|---|---|---|
| Transmission security, 164.312(e)(1) | TLS on client routes (HTTPS, commonly port 9443), with TLS terminated at the gateway | Approved protocol versions and cipher suites set on each SSL object, certificate inventory, and a documented list of routes that must not accept plain HTTP on port 9080 |
| Integrity controls (addressable) | TLS provides message integrity in transit; confirm any additional request signing or body checks your design needs with a plugin for your version | Decision record on whether transport integrity alone is reasonable and appropriate, or whether HMAC or signed payloads are added for specific ePHI routes |
| Encryption (addressable), in transit | Upstream TLS to services and mTLS from the gateway to upstream services, configured on upstream objects | Documented upstream CA trust, client certificate issuance and rotation records, and the reason for any unencrypted internal hop |
| Audit controls, 164.312(b) | Logging plugins such as http-logger, file-logger or syslog-based options that record API access metadata; confirm the fields each plugin emits | Log schema that records who called which route, when, and with what result, with request and response bodies excluded from the log pipeline |
| Unique user identification, required | Consumer objects with key-auth or jwt-auth, and openid-connect for identity provider sign-in with per-user tokens | Consumer naming rules, no shared API keys across staff or partners, and a register linking each consumer to a named owner |
| Automatic logoff, addressable | Token lifetime and session settings in the identity provider, enforced at token validation in openid-connect or jwt-auth; confirm refresh and session options in your version | Access token and refresh token lifetimes written into the policy, and tests showing expired tokens are rejected at the gateway |
| Administrative access to the gateway | Admin API on port 9180 in traditional mode, which should be bound to a management network and protected by an admin key and TLS | Network rules limiting port 9180, rotated admin credentials, and change records for every route or plugin edit |
| Risk analysis and documentation evidence | Gateway configuration exported as code, with version control and deployment history for each change | Diagram of ePHI flows through the gateway, the risk entries for each route, and sample log extracts that show no payload content |
Configuring TLS and mTLS for client and service traffic
Client-facing TLS for an APISIX gateway terminates at the gateway, so the gateway is the point where ePHI in transit is either protected or exposed. Start by mapping every hop that carries ePHI: the client to the gateway, the gateway to each upstream service, and any service calling another service through the gateway. Each hop that carries ePHI needs an encryption decision, and 45 CFR 164.312(e)(1) requires technical measures against unauthorized access to ePHI sent over a network. Under 45 CFR Part 164 Subpart C, encryption is an addressable specification, so the decision must be documented: either the hop is encrypted, or the risk assessment explains why not and what equivalent measure applies. Hops that carry only non-sensitive metadata still belong on the map, because a later change can move ePHI onto them.
On the gateway, TLS certificates and their private keys should have a named owner, a documented issuance source and a rotation procedure that does not depend on one engineer. Decide whether the gateway accepts client certificates for service-to-service calls, and whether the upstream connections require TLS and a client certificate presented by APISIX. Keep the Admin API and any key material out of the client-facing listener, and confirm where APISIX stores certificates and secrets in your chosen deployment mode. Confirm with your own team which encryption tooling, such as a secrets manager or internal certificate authority, already holds the private keys before you wire them into the gateway.
Protocol versions and cipher suites must follow your organization's approved cryptography policy, not defaults shipped with a gateway release. NIST SP 800-52 is an informational reference for TLS configuration, and HHS lists it in its Security Rule guidance without making it binding. Ask your security team to write the approved protocol and cipher list, then test the running gateway against it with an external scanner after each change. Record the test output, the certificate inventory and the owner of each certificate as evidence for your HIPAA risk analysis, since those records show how the transmission security decisions were made and kept current.
Sequence for a HIPAA-aligned APISIX transmission setup
This sequence turns the ePHI API inventory from the risk analysis into a gateway configuration where encryption, authentication, logging and denial behavior are each set, tested and recorded in version control. Each step names the evidence it produces for the risk analysis file.
Inventory ePHI API flows from the risk analysis
Your privacy or security lead, with the application owners, lists every API route that creates, receives, stores or transmits ePHI, including calls between internal services and calls to business associates. For each flow, record the client type, the upstream service, the data classification and the business associate that handles it. The step is complete when every route in the gateway plan traces back to a named item in the risk analysis. Gaps found here usually point to routes nobody has documented yet, so resolve them before any configuration is written.
Choose the deployment mode for the ePHI gateway
Your platform team decides between traditional, decoupled and standalone mode, using the APISIX deployment modes documentation as the reference. Traditional mode runs data and control planes together, decoupled mode separates them over one etcd cluster, and standalone mode loads configuration from a file or the API without etcd. The choice drives where the Admin API lives and how changes are approved. The step closes with a written decision that names the mode, the hosting boundary and who can change routes. Confirm with your security team whether the chosen mode fits your hosting and change control obligations.
Lock down the Admin API and etcd
Your platform engineers restrict the Admin API, which listens on port 9180 in traditional mode, to a management network and separate it from client traffic on port 9080. They also limit network access to etcd, require authenticated and encrypted connections between APISIX and etcd, and remove default credentials. The check is a connection test from a client subnet that must fail, plus a scan confirming that neither management port is reachable from outside. Record the firewall rules and the etcd settings as evidence for the access control part of the risk analysis.
Enable TLS and upstream mTLS on ePHI routes
Your platform team installs server certificates for the client listener and configures SSL objects so that ePHI routes accept only the TLS versions and cipher suites your cryptography policy approves. For traffic from the gateway to internal services, they enable mutual TLS with client certificates issued by an internal certificate authority. Per 45 CFR 164.312(e)(1), this addresses the transmission security standard, and the encryption implementation specification is addressable, so document your reasoning. The step is done when a TLS scan of the public endpoint and a handshake test to each upstream both show the expected protocol and certificate chain.
Attach authentication and consumer identity
Your identity team and the API owners attach an authentication plugin to each ePHI route, such as openid-connect for workforce or partner tokens, or key-auth and jwt-auth for system consumers. Each caller is registered as a consumer so that every request maps to one identifiable account or service. Unique user identification is a required implementation specification under 164.312, so shared API keys should not be used for ePHI routes. The check is that a request without credentials is rejected and that the log entry shows the consumer name for an accepted one.
Configure access logs without request or response bodies
Your platform engineers configure the access log format to record the timestamp, consumer identity, route, method, status code, source address and request identifier, and they leave out request and response bodies and sensitive headers. Logs are forwarded to a protected central store with restricted read access. Under 45 CFR 164.312(b), the mechanism must record and examine activity, so the log format should support the review your procedures require, without copying ePHI into a second system. Confirm the log retention period with your compliance lead, since this page does not set one. The step closes with a sample log extract showing that no payload fields appear.
Test denial paths and failure behavior
Your security engineers run a test set that sends expired tokens, unknown consumers, requests over plain HTTP, unsupported TLS versions and calls to the Admin API from an unauthorized network. Each request must be denied with the expected status code and must produce a log entry. They also confirm that a failed upstream certificate check blocks the call rather than falling back to an unencrypted connection. Store the test results with the configuration baseline so an assessor can see both what was allowed and what was refused.
Record configuration in version control
Your platform team stores route definitions, plugin settings, certificate references and deployment files in a version control system with reviewed changes and signed-off approvals. Secrets and private keys stay in a secrets store and out of the repository. Each production change links to a ticket and a test result, which supports the change records a risk analysis and later audit will ask for. The step is complete when a configuration in the repository can be reproduced in a test environment and the approved baseline matches the running gateway.
Evidence an APISIX gateway can produce for a HIPAA risk analysis
A HIPAA risk analysis asks what can reach ePHI, how it is protected in transit and who touched it. The artifacts below are the gateway records a reviewer will ask for, and each one should be tied to a specific system, owner and retention rule. The organization decides what counts as sufficient for its own risk analysis.
Route and TLS configuration exports
Export the route, upstream and SSL object definitions that APISIX holds, including which routes accept HTTPS only, which TLS protocol versions and cipher settings are enabled, and which routes carry ePHI. Store each export with a date and the commit or change ticket it came from. Check that the export matches what the running gateway actually serves, since a configuration file and the live state can drift apart in a deployment that accepts both API and file changes.
Certificate inventory with expiry and ownership
Keep a current inventory of every certificate and private key used on client-facing listeners and on upstream connections, including mTLS client certificates. Record the subject, issuer, validity dates, the routes or services that use each certificate, and the named owner responsible for renewal. Reviewers use this to test whether encryption in transit was in place continuously, so gaps caused by an expired certificate are as important as the initial setup.
Access logs with consumer identity
Configure the gateway to log the authenticated consumer, request path, method, status code, timestamp and source address for each API call that touches ePHI, while leaving request and response bodies out of the log. Confirm in a test that a sample request with a dummy identifier produces the expected fields and no payload content. The log design should be agreed with the privacy and security owners before go-live, because a body field added later can turn an access log into a copy of ePHI.
Admin API audit records
Changes made through the Admin API, including new routes, plugin enablement, consumer creation and credential rotation, should be attributable to a named operator. Confirm how your deployment authenticates Admin API calls, where those calls are logged, and whether the audit trail lives on the gateway host or in a central system. Restrict the Admin API to a management network, since its records are only useful if the interface cannot be reached by ordinary API clients.
Change history for gateway configuration
Keep gateway configuration under version control so that every change to routes, plugins and certificates has an author, a reviewer, a timestamp and a linked request. Where the deployment uses file-driven standalone mode, the YAML or JSON file is the configuration of record and its history answers most change questions. Compare the approved history against the running state at each review date to show that no unapproved changes were applied.
Test results and the risk analysis link
Keep dated results from TLS scans against the client listeners, mTLS handshake tests for service connections and log-content checks that confirm no PHI payloads are written. Map each result to the risk analysis entry it supports, such as the transmission security risk for a specific API, and record the residual risk and any addressable specification decision. Ask your privacy and compliance leads to confirm which results they consider sufficient, since the regulation does not prescribe a fixed set of tests.
Logging API access without writing PHI payloads to logs
The core decision in this section is to log access records, not payloads. An access record answers who called which route, when, from where, and with what status code. A payload is the request or response body, which on an ePHI route is where patient identifiers, diagnoses and billing details actually sit. Access records are what 45 CFR 164.312(b) asks you to capture: mechanisms that record and examine activity in systems that contain or use ePHI. Nothing in that requirement calls for copying the message content into the log pipeline. Turning on request and response body logging for an ePHI route creates a second, less protected copy of PHI in a store that many more people and tools can query than the clinical system behind the API.
In APISIX, the practical control is the access log format and the logging plugins that consume it. Review the log_format setting and any plugin that captures bodies, such as http-logger or similar sinks, and confirm that request and response body fields are absent for ePHI routes. Keep the fields you need for investigation: timestamp, route ID, consumer or subject identifier, client address, method, path template rather than path parameters that embed identifiers, status and latency. Where a path parameter may carry a patient or record identifier, decide whether to log the template or a keyed hash, and document that choice. Confirm the exact field names against the APISIX version you deploy, because the logging plugins and their options change between releases.
Logs then need a protected destination and a retention rule, and both should be written into the risk analysis. Route access records to a store with restricted read access, separate from general application logs, and log the access to that store itself. Set retention in line with your documented policy and with the documentation period your compliance program requires, and confirm the figure with your privacy and legal teams rather than copying a default. Once the field list, destination and retention are agreed, the build and verification steps are covered in Apache APISIX deployment and operations guidance as the next read.
What the gateway does not cover under the Security Rule
APISIX can carry much of the transmission security evidence for ePHI APIs, but the Security Rule is broader than the gateway. Each item below needs a named owner, its own policy, and its own evidence file, and none of them is satisfied by a gateway configuration alone.
Risk analysis and risk management
The Security Rule expects an accurate and thorough assessment of risks to ePHI, followed by risk management measures. The gateway appears in that analysis as one asset among many, with its threats, exposures and residual risk recorded. Ask who owns the analysis, how often it is refreshed after gateway changes, and whether the risk register links each APISIX route that carries ePHI to a documented decision.
Policies and procedures
Written policies and procedures must describe how the organization applies each safeguard, including who may change gateway routes and certificates. A YAML file in a repository does not replace the approved procedure. Confirm that the APISIX change, certificate renewal and incident steps are written, approved, versioned and reviewed by a named role.
Workforce access reviews
Access to the Admin API, the etcd cluster and the TLS private keys is a workforce question as much as a gateway setting. Periodic reviews should confirm that each administrator still needs that access and that departed staff were removed from the identity provider and from any gateway credentials. Ask who runs these reviews and where the signed results are stored.
Database and application encryption
TLS at the gateway protects data in transit only. ePHI at rest in PostgreSQL, object storage, logs and backend application caches needs its own encryption design, key ownership and rotation. Confirm which systems hold ePHI after the gateway forwards a request, and assign each store its encryption control and evidence.
Endpoint and device controls
Clinicians and staff reach ePHI APIs from laptops, mobile devices and shared workstations that the gateway cannot inspect. Endpoint encryption, screen locking, malware protection and device management belong to the endpoint program. Ask who manages those controls and how their status is reported to the security team.
Business associate agreements under 164.314
Under 45 CFR 164.314(a), a business associate contract must require Security Rule compliance, flow the same terms to subcontractors that handle ePHI, and require reporting of security incidents. If a partner hosts or operates the gateway, that relationship needs a signed agreement. Confirm who holds the agreement, which subcontractors touch ePHI, and whether the gateway vendor or service provider is covered.
Incident response and physical safeguards
Incident response procedures decide who investigates a suspected exposure, how it is contained and when it is reported. Physical safeguards cover facility access, workstation placement and the disposal of media that held ePHI or gateway keys. The gateway logs help an investigation, but the response plan, the contact tree and the facility controls must be documented and tested by their own owners.
Questions buyers ask before outsourcing HIPAA transmission security
What drives the effort and cost of securing ePHI APIs on APISIX?
The main drivers are the number of routes that carry ePHI, how many upstream services sit behind them, and how clients authenticate. Each additional route needs its TLS settings, client certificate rules, authentication plugin and log handling reviewed and tested. Identity integration adds work when the identity provider, token lifetimes and claim mapping are not yet settled. The log pipeline matters too, because access records must be shipped, retained and protected without capturing PHI payloads. Evidence scope is the last driver: a narrow set of routes documented for one risk analysis costs less than a gateway estate with every service mapped. Setup work is usually one-time, while certificate renewal, policy review and upgrades recur. Ask any quote to itemize these items separately, state which systems are in scope, and say who owns each recurring task after handover.
Can our internal team secure ePHI APIs on APISIX without a partner?
Often yes, if the team already runs TLS, identity and Kubernetes or Linux operations and has time to learn APISIX's Admin API, plugins and deployment modes. The gap usually sits in HIPAA-specific work: mapping each control to the Security Rule, documenting why an addressable specification was chosen or declined, and proving the configuration matches the design. An internal team should confirm three things before starting: it can test the gateway under realistic failure and rollback conditions, it can keep configuration under change control, and someone can own the risk analysis. A partner is most useful where the team lacks one of these skills or needs an independent build review. Compare the cost of staff time, training and ongoing ownership against a fixed-scope engagement written in advance.
What do we need to provide before the transmission security work starts?
The work depends on information only your organization can supply. Prepare these items before scoping:
- An architecture inventory listing every API that creates, receives, stores or transmits ePHI, its upstream services and its consumers.
- A certificate authority decision, covering whether certificates come from an internal CA, a public CA or a managed service, and who approves issuance and renewal.
- Identity provider access for test and production tenants, with the client types, scopes and claims the gateway will use.
- A named risk analysis owner who can accept findings and decide on addressable specifications.
- Access to the log destination and its retention rules.
Missing items usually extend discovery and move decisions into the build phase, so confirm them in writing before the statement of work is signed.
Does HIPAA certification exist for APIs or gateways?
No. HIPAA has no certification. HHS states that no Security Rule standard requires an entity to certify compliance, that it does not endorse or recognize private certifications, and that such certifications do not stop HHS from later finding a violation (HHS FAQ 2003). The Office for Civil Rights enforces the Security Rule through complaint investigations, compliance reviews and audits. Be cautious with any vendor or consultant offering a HIPAA certificate for a product or deployment. Ask instead for documented risk analysis results, configuration evidence, test records and a clear mapping to the technical safeguards in 45 CFR 164.312. Those records are what an OCR reviewer or your own auditor would examine.
How should the 2026 HIPAA penalty range affect our scoping?
The inflation-adjusted range for penalties assessed on or after January 28, 2026 runs from $145 per violation with no knowledge to $2,190,294 per violation for uncorrected willful neglect, with a calendar-year cap of $2,190,294 (45 CFR 102.3). The range shows why the record of decisions matters as much as the configuration. A penalty turns on the entity's knowledge, its response and whether violations were corrected, so scope should include the documented risk analysis, the reasons behind each addressable choice and the monitoring that shows issues were found and fixed. Do not read the figure as a prediction of your exposure. Confirm current figures in the eCFR before you use them in a board paper.
Does the HIPAA Security Rule change soon, and should we wait?
Do not wait. HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898, RIN 0945-AA22), with comments due March 7, 2025. As of October 2026 no final rule has been published, and the latest Unified Agenda lists it under Long-Term Actions with final action projected for July 2027. The current rule in 45 CFR Part 164 Subpart C still applies. Designing the gateway around the existing technical safeguards, with TLS, unique identification, audit controls and documented decisions, creates a base that a later rule would most likely build on. Ask your advisers to track the rulemaking and to note any change that would require a configuration or documentation update.
How does the gateway work with our log pipeline without storing PHI?
The gateway should record who called which route, when, from where, and with what result, but not the request or response body. Typical design choices include logging only selected headers and identifiers, masking or excluding payload fields, and sending logs to a protected store with access control and retention set by policy. Engineers should test the log format with sample ePHI-bearing requests before go-live and confirm that no query parameters or tokens carry patient identifiers into the log. Logging must also satisfy 45 CFR 164.312(b), which requires mechanisms that record and examine activity in systems that use ePHI. Confirm the exact APISIX logging plugin behavior and field options in the current documentation for your release before you finalize the format.
Planning around the proposed Security Rule update
Design your APISIX transmission security evidence to the Security Rule as it stands today, and plan a formal reassessment when HHS publishes a final rule. HHS proposed a major revision to the HIPAA Security Rule on January 6, 2025 (90 FR 898, RIN 0945-AA22), with comments due March 7, 2025. As of October 2026, no final rule has been published, and the latest Unified Agenda lists the rulemaking under Long-Term Actions with final action projected for July 2027. The proposal is not binding, so the controls you can defend today are the ones in 45 CFR 164.312, not the proposed text.
Some of the proposed changes would, if finalized, affect this design. The proposal is widely reported to add more prescriptive expectations for encryption and for verifying technical controls, so confirm the specifics against the proposed text in the Federal Register before you draft new requirements. In practice, keep the gateway evidence in a form that can be extended: the TLS settings in your APISIX configuration under version control, the mTLS trust chain documented with its owners, and log retention and review records kept with dates. Ask your compliance lead which of these artifacts would need to change if the final rule adds requirements, and record that answer in your risk analysis.
Set a review trigger now rather than waiting for the rulemaking to finish. Assign an owner to watch the Federal Register and the Unified Agenda entry for RIN 0945-AA22, and schedule a review of the gateway's risk analysis within a period your governance process sets when a final rule appears. Also review when APISIX releases change TLS defaults, when you upgrade the gateway or etcd, or when a new client or partner connects to ePHI routes. An outside implementation partner can help map each proposed change to a route, certificate or log source, but the covered entity or business associate still decides what is reasonable and appropriate for its environment.
How DeployOpen scopes and delivers HIPAA transmission security work
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, so the APISIX gateway that carries ePHI runs in cloud accounts, data centers or networks you control. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory every API route that carries ePHI, including the clients, upstream services and networks on each path.
- Record which TLS and mTLS links, certificate sources and gateway log destinations are in scope for the written scope.
- Agree the evidence package upfront, such as configuration exports, log samples and test results, before work starts.
How we build
- Configure TLS to clients and mTLS to upstream services in your APISIX deployment, with protocol and cipher settings you approve.
- Set access logging so API activity is recorded without writing PHI payloads, and test that redaction against sample traffic.
- Test the configured gateway with protocol scans and negative tests, then document results against your risk analysis.
How we hand over
- Deliver configuration as code, runbooks, certificate rotation procedures and the logging design for your security team.
- Document how each gateway control maps to your HIPAA risk analysis, noting which items remain your organization's decisions.
- Walk your engineers through operating the gateway, with handover criteria agreed in the written scope.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering APISIX releases and certificate changes.
- Review gateway configuration changes against the documented baseline when your teams modify routes or plugins.
- DeployOpen prepares systems and evidence for assessments but does not issue HIPAA certifications or audit reports.
