How Apache APISIX supports SOC 2 boundary protection evidence
If your SOC 2 scope includes externally reachable APIs, the auditor will ask how the system boundary is controlled, and the answer often sits at the API gateway. Apache APISIX can support evidence for CC6.6, CC6.7 and CC7.2 by enforcing authentication, access restrictions, encryption in transit and request logging at the gateway. It does not satisfy SOC 2 on its own, and DeployOpen does not certify or attest to compliance; that judgment belongs to an independent CPA firm performing the examination. The gateway is one layer of the control set. It does not touch identity lifecycle management, change approval for the wider application, vendor management, backup and recovery, or the people processes that the auditor will also test.
Start by mapping each external route to the control it evidences. For CC6.6, the question is whether every route that crosses the boundary has an authentication plugin or a deliberate, documented reason to be open. In APISIX that means reviewing the routes configured through the Admin API or declared in configuration, checking which use plugins such as openid-connect, jwt-auth or key-auth, and recording consumer ownership. For CC6.7, the question is how data leaves the system, which points to TLS settings on listeners and upstream connections. Confirm with your security team which protocol versions and cipher policy the gateway enforces, because defaults change between releases and the auditor will test the configuration you actually run.
For CC7.2, the gateway contributes logs and monitoring signals, but the anomaly analysis and the decision about whether an event is a security event still need an owner and a documented procedure. Decide where access logs go, who reviews rate-limit and denial events, and how a reviewer records their conclusion. Ask your CPA firm early which population of gateway logs they will sample and over what period, since a Type 2 examination tests whether these controls operated over time, not only that they were configured. DeployOpen can plan and document this evidence trail with you, within the scope agreed in writing.
Mapping CC6.6, CC6.7 and CC7.2 to APISIX capabilities and configuration
This table maps each SOC 2 common criterion in scope for boundary protection to the APISIX plugins, deployment choices and configuration an assessor will ask about. Read each row as a question to answer with a route, a consumer or a log source, then confirm the plugin names against the APISIX version you run. The main takeaway is that the gateway supports these criteria only when every external route inherits the same authentication, restriction and logging policy.
| Requirement and focus | APISIX capability | Configuration to build |
|---|---|---|
| CC6.6 boundary protection: restrict access to the system from outside its boundaries | Traditional or decoupled deployment with client traffic on port 9080 and the Admin API on port 9180, plus ip-restriction and limit-req or limit-count plugins | Expose only the client listener to external networks, restrict the Admin API to an internal management network, and define an allow list or deny list per route where the business allows it |
| CC6.6 credential protection: protect identification and authentication credentials | openid-connect, key-auth, jwt-auth, basic-auth, ldap-auth and forward-auth plugins, with consumers holding API keys or signing secrets | Store upstream and consumer secrets outside route definitions, rotate consumer credentials on a documented schedule, and confirm how your APISIX version handles secret references |
| CC6.6 additional authentication: require additional authentication or credentials | multi-auth plugin to combine methods, openid-connect for authorization code, client credentials and token introspection flows, and PKCE where clients support it | Define which routes accept which credentials, require a second factor at the identity provider for workforce access, and test that routes without a valid credential return a denial |
| CC6.7 transmission protection: protect information while it is transmitted | TLS termination on the client listener, upstream TLS settings on each route, and HTTP/3 with QUIC where enabled in your build | Set approved TLS protocol versions and cipher suites, configure certificates for each host, and document where traffic is re-encrypted before it reaches internal services |
| CC6.7 limiting movement: limit transmission to authorized users and processes | Route-level matching, consumer scoping, and plugins that restrict methods, request size and response headers | Map each route to named consumers or upstream services, deny unlisted HTTP methods and paths, and keep the route inventory under version control for review |
| CC7.2 monitoring: detect anomalies that indicate malicious acts or errors | Access logs and plugin logging to external systems, rate limiting counters, and plugin runners in Java, Go, Python or WebAssembly for custom detection logic | Send gateway logs to your monitoring platform, define alert thresholds for denied requests and rate limit hits, and document who reviews alerts and how events are classified |
| Evidence across all criteria: show the configuration as it operated over the audit period | Configuration held in etcd in traditional or decoupled mode, or in a versioned YAML or JSON file in standalone mode with reload checks every second | Keep configuration in version control with change approvals, retain snapshots for the period, and confirm with your auditor which change records they will sample |
Which gateway evidence auditors ask for and how to keep it
A SOC 2 auditor testing boundary protection will ask to see how the gateway was configured, how that configuration changed, who could reach it, and what it recorded. The six items below map to those questions, and each one needs a defined period, a tamper-evident store and a custodian who is not the engineer whose work is being examined.
Route and plugin configuration export
Export the live routes, upstreams, consumers and plugin settings from the Admin API, or from the configuration repository if you manage APISIX as code. For a Type 2 report, the auditor needs evidence that the settings were in place across the whole examination period, so take dated snapshots on a fixed schedule rather than one export at the end. Check that every route that reaches an external client shows an authentication plugin and a restriction plugin in the export. Store snapshots in write-once storage that the gateway operators cannot edit.
Gateway change history
Auditors will ask who changed a route, plugin or certificate, when, and who approved it. If configuration lives in Git, the commit history, pull request reviews and deployment records answer those questions together. If engineers change routes through the Admin API directly, you need an audit trail from the change process instead, and that gap is common in gateways that started as a quick proxy. Confirm that emergency changes leave a record and receive a retrospective review. Sample a few changes against tickets during the period to test the link.
Identity provider and consumer lists
Record which identity providers the openid-connect plugin trusts, which client IDs and consumers exist, and which credentials are issued to each. Keycloak, Auth0, Microsoft Entra ID, Google and Okta are common examples, but the list should come from your own configuration. Auditors test CC6.6 by checking that consumer lists match approved owners and that revoked consumers no longer authenticate. Export these lists with the same dated cadence as route snapshots, and reconcile them against the identity provider's own records.
Access and error logs with retention
Access and error logs show which clients reached which routes and which requests the gateway rejected. Define the retention period in your written policy before the examination starts, and confirm that the log pipeline holds the full period without silent gaps. Ship logs off the gateway host to a central store that the gateway administrators cannot delete from. Remove or mask personal data and secrets from log fields, such as query strings and authorization headers, before retention begins, so the logs themselves do not become a new exposure.
TLS certificate inventory and protocol settings
Keep an inventory of every certificate the gateway serves, with issuer, subject names, expiry date and the owner responsible for renewal. Record the TLS protocol versions and cipher settings in effect, and the dates they changed. Auditors use this to test CC6.7 protection of information in transit. Compare the exported settings against your approved cryptography policy and note any exceptions with a documented reason. Expired or unknown certificates found during testing are common findings, so reconcile the inventory against what the gateway actually presents.
Alert records for anomalous traffic
CC7.2 requires monitoring for anomalies and analysis of whether they are security events, so keep the alert rules, the alerts that fired and the triage notes for each. Rate limit rejections, repeated authentication failures and unusual spikes on a route are typical signals to define. Auditors will sample alerts and ask for the ticket showing who reviewed each one and what was decided. An alert that fired with no recorded review is a gap, even if the traffic was benign. Store the alert rules under the same change control as the routes they watch.
How the boundary configuration changes by API type
Public APIs receive requests from customers on the internet, so the gateway is the first point where unauthenticated traffic can be refused. For customer-facing routes, the usual pattern is the openid-connect plugin in front of an identity provider such as Keycloak or Microsoft Entra ID, with tokens validated at the gateway before any request reaches an upstream service. IP and rate restrictions still matter here, but they work as a second layer rather than the main control, since customers arrive from unpredictable addresses.
- Authentication on every route: Attach the authentication plugin to each public route in configuration, not only to the routes that look sensitive.
- Token validation: Configure audience, issuer and expiry checks so tokens issued for another application are rejected.
- Rate limits: Set per-consumer or per-route limits to reduce abuse of login and search endpoints.
- Access logs: Record authentication outcomes and rejected requests with a consistent request identifier.
The auditor will usually sample a route list, the plugin configuration applied to each route, and a set of rejected requests showing the gateway refused an unauthenticated call. Confirm with your identity provider team which token lifetimes and client settings your policy requires.
Partner integrations are machine-to-machine, so there is usually no user session at the gateway. The common pattern is key-auth or jwt-auth for partner clients, with each partner modeled as a consumer. Where the partner's own identity provider issues client credentials, the openid-connect plugin can validate client credential tokens instead. The design choice is mainly about how credentials are issued, rotated and revoked, and whether partners can be restricted to a set of source networks.
- Consumer per partner: Create one consumer per partner so credentials, limits and logs can be traced to a single party.
- Source restrictions: Use the IP restriction plugin to allow only the partner's agreed address ranges where the partner can supply them.
- Credential rotation: Document how keys are issued, rotated and revoked, and who approves each change.
- Scoped limits: Apply rate limits per consumer so one partner cannot degrade service for others.
Auditors commonly ask for the consumer list, a sample of partner agreements or onboarding records, and proof that a revoked credential is rejected. Ask your team to confirm how partner credentials are stored, since the Admin API and secret handling sit in the gateway hardening scope.
Internal services sit behind the gateway and should not be reachable directly from outside. For these routes, the gateway usually verifies the caller's identity and passes it upstream, while the service network enforces that only the gateway can reach the service. Forward-auth is useful when an external policy service must decide each request, for example when access depends on device state or a central authorization decision. Mutual TLS between the gateway and services is a stronger option where the environment supports it.
- Network path: Confirm the upstream services accept traffic only from the gateway address range or the gateway workload identity.
- Forward-auth: Use the
forward-authplugin to delegate per-request decisions to a policy service, and log its responses. - Identity propagation: Pass verified identity headers upstream, and make sure clients cannot spoof those headers.
- Restrictions: Apply IP restrictions to management or debugging routes that should only be reached from operations networks.
The auditor will look for evidence that internal paths cannot be bypassed, which means a network diagram, the upstream configuration and a test showing a direct call fails. Ask your platform team to confirm where the boundary is drawn in your environment.
Administrative endpoints, including the APISIX Admin API and any operator interface, carry the highest risk because they can change routes, plugins and credentials. In traditional deployment mode the Admin API listens on port 9180 and client traffic on port 9080, so the Admin API should never be published on the same path as public traffic. Access should be restricted to a small set of operator networks, use strong credentials, and be recorded. Client traffic for administrators should go through the identity provider with multi-factor authentication where the environment supports it.
- Separate listener: Keep the Admin API off public interfaces and firewall it to named management hosts.
- Strong admin credentials: Replace default keys and store them in your secrets management system.
- IP restriction: Allow access to management endpoints only from the operations network.
- Change logging: Keep an audit trail of every configuration change, with the operator and the change reference.
Auditors typically sample the firewall rules, the Admin API key configuration, and change records for recent gateway modifications. Confirm with your security team how administrator access is approved and reviewed, because that process sits outside the gateway configuration itself.
Why a single enforcement point helps the boundary argument
Placing authentication, IP and rate restrictions, and TLS termination at one gateway gives the auditor one place to test for CC6.6 boundary protection. Instead of sampling authentication logic inside every service, the assessor can read the route inventory, the plugin configuration attached to each route and the consumer definitions, then check whether every external route carries the expected controls. That reduces the number of configurations a control owner must explain and makes the population of external routes easier to define at the start of the examination period. The argument only holds if the gateway's route list is complete, so confirm with your team how external routes are discovered and how a route that bypasses the gateway would be detected.
The gateway is built on NGINX with etcd as its configuration store, and configuration can be hot-loaded through the Admin API or, in standalone mode, by file changes that the gateway picks up without a restart. This matters for change management. A rule that allows a new path, removes a rate limit or disables an authentication plugin can reach production without a code deployment, so change control must cover route, plugin and consumer configuration as well as application code. Ask your team to define who may write to the Admin API, how configuration is versioned in Git, and what approval and record each change needs, so that the configuration history can serve as evidence for CC8.1 and the boundary controls alike.
The management plane needs the same scrutiny as the traffic plane. In traditional deployment mode APISIX listens on port 9080 for client traffic and port 9180 for the Admin API, and the Admin API can change every route and plugin. Keep port 9180 off public networks, bind it to a management interface or restrict it with network policy, and confirm the port is not exposed through a load balancer or Kubernetes service. Treat the separation of these two ports as a control to document and test, because an auditor will ask how an external party could reach the configuration interface, and a clear answer with a test result is far stronger than a diagram alone.
Configuration sequence for SOC 2 boundary controls
This sequence turns an APISIX gateway into boundary evidence that maps to CC6.6, CC6.7 and CC7.2, with each step producing an artifact the auditor can sample. The order below is a recommendation, and the scope agreed with your auditor should set the final boundary.
Inventory external routes and confirm the boundary
Before any configuration, list every route, host and port that accepts traffic from outside your system boundary, and record which upstream services each one reaches. Agree this boundary with your SOC 2 auditor, since it determines which criteria apply to the gateway and which systems sit inside scope. Done means you hold a signed-off route inventory that ties each entry to an owner and a business purpose, which supports CC6.6 by showing the organization knows what faces threats from outside its system boundaries.
Separate client and admin listeners
Keep client traffic on the data plane listener and move the Admin API to a separate, restricted interface, restricting it to a management network or bastion hosts. In traditional deployments APISIX listens on port 9080 for client traffic and port 9180 for the Admin API, so confirm both settings in your configuration files and firewall rules. Done means a test from an external network reaches only the client listener, and the record of that test is retained as CC6.6 evidence of restricted access.
Require authentication on every external route
Attach an authentication plugin to each route in the inventory, such as openid-connect for workforce or partner sign-in, or key-auth and jwt-auth for machine clients. Define consumers with individual credentials, and store signing material and client secrets outside plain configuration files. Done means a scripted check of the route inventory returns an authentication requirement for every entry, with any exception documented and approved, which addresses the CC6.6 focus on requiring additional authentication or credentials.
Add IP and rate restrictions per route
Apply IP allow lists and request rate limits to each route according to its expected callers, rather than relying on one global policy. Test the restrictions with allowed and denied source addresses and with traffic above the configured threshold, and confirm the denied requests appear in logs. Done means the test results and the route-level configuration are stored with the change record, supporting CC6.6 boundary protection. The exact plugin names and parameters should be confirmed against the APISIX version you deploy.
Enforce TLS and manage certificates
Configure HTTPS on client listeners, select protocol versions and cipher settings your policy approves, and set up a documented process for issuing, renewing and revoking certificates. Confirm that traffic between the gateway and upstream services is also encrypted where your data classification requires it. Done means a TLS scan of each external hostname matches the approved settings and the certificate inventory lists owners and expiry tracking, which evidences CC6.7 protection of information while it is transmitted.
Ship access and anomaly logs to a central system
Enable access logging on every route and forward gateway logs to a central log platform that your team controls, with retention set by your policy. Define alert rules for patterns such as authentication failures, rate limit breaches and unusual request volumes, and document who reviews the alerts and how a potential event is escalated. Done means a sample of alerts shows that a test anomaly was detected, triaged and recorded, which supports CC7.2 monitoring and analysis of anomalies.
Export configuration and document change control
Store gateway configuration in version control, export the running state on a regular basis, and require review and approval before changes reach production. Record who approved each change and link it to a ticket describing the reason. Done means the auditor can pick any change in the period and trace it from request to approval to deployment, which supports the change evidence that SOC 2 engagements commonly request under the change management criteria.
Run a control walkthrough with evidence samples
Walk through each control with the people who operate it and collect samples: route inventory, authentication test results, restriction tests, TLS scan output, sample logs and alert records, and change tickets. Check that every sample matches the written control description and fix any gaps before the auditor arrives. Done means a binder or evidence folder maps each sample to its criterion, and your auditor has confirmed which samples they want for the examination period.
What the gateway does not cover for SOC 2
An APISIX gateway covers one part of the evidence a SOC 2 examination looks for: the traffic crossing the system boundary. The cards below set out what remains with your organization, your processes and your auditor, so the gateway is not presented as more than it is.
System description and management assertion
The gateway does not write the system description that management prepares under the AICPA description criteria, and it cannot make the management assertion that the auditor requires in writing. Those documents must name the gateway, its routes, its trust boundaries and the people who operate it. Check that the description states what APISIX enforces and what sits outside it, and that management owns and signs both documents.
Endpoints, databases and internal traffic
CC6.6 concerns threats from outside the system boundary, so the gateway protects only the traffic routed through it. Endpoints, databases, message brokers and east-west traffic between internal services are not covered unless they also pass through APISIX or have their own controls. Inventory every path into each system component and record which controls protect each one.
Anomaly rules and response process
CC7.2 asks you to monitor for anomalies and to decide which ones are security events. APISIX can emit logs and metrics, but it does not know what normal traffic looks like for your APIs. Your team must tune thresholds, define alert conditions, assign owners and record how each alert was analyzed and closed.
Identity lifecycle and access reviews
The openid-connect and key-based plugins enforce the credentials they are given, but they do not onboard or offboard people, rotate consumer credentials on a schedule or review who still holds access. CC6.6 also expects protection of authentication credentials. Your identity provider, joiner and leaver process and periodic access reviews must be documented and tested separately from the gateway.
Change management for gateway configuration
Routes, plugins and policies change through the Admin API, configuration files or Kubernetes resources, and each change can alter what the boundary allows. The gateway does not approve or record these changes for you. Decide where configuration lives, who may change it, and how each change is reviewed, tested and traced to a ticket.
Commercial feature availability
This section does not assume that any feature from API7 Enterprise, the commercial product built on APISIX, is available in your deployment. Features for audit logging, centralized policy or lifecycle management must be confirmed directly with the vendor for your version and license before they are cited as controls in your evidence.
What do SOC 2 boundary controls cost and take to build?
What drives the effort of building APISIX boundary controls for SOC 2?
The main drivers are the number of external routes, how many identity providers the routes must trust, how logs are shipped and retained, what monitoring already exists, and how much of the system the SOC 2 system description covers. Each external route needs an authentication decision, a restriction decision and a logging decision, so route count multiplies the work. An identity provider integration that uses an existing OpenID Connect setup is usually simpler than one that needs new claims mapping or several token flows. A log pipeline that already receives gateway logs is cheaper to extend than one built from nothing. Scope of the system description matters most of all, because it determines which controls the auditor will sample and how much evidence must be collected for each.
Can our internal team build SOC 2 boundary controls on APISIX?
Yes, if the team already has skills in gateway configuration, identity protocols and audit logging, and if it has enough capacity for the work alongside its normal duties. The gateway work is configuration, plugin selection and testing, but the evidence work is easy to underestimate: change records, access reviews, log retention settings and documented monitoring rules all have to exist and be consistent with what the system description says. Teams without someone who owns the SOC 2 control set often find the evidence gaps only when the auditor asks for them. Whether to build internally or with a partner depends on that team's current capacity, not on the platform alone.
How long does a SOC 2 boundary protection engagement take?
The duration depends on the same factors as the effort: route count, identity integration, logging and the scope of the system description. DeployOpen engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts, and that written plan is the reliable source for dates. Ask for a timeline that separates gateway configuration, identity integration, logging, testing and evidence collection, because the evidence phase often runs for the length of the observation period in a Type 2 examination rather than in the build window.
What must our team provide before a SOC 2 gateway engagement starts?
Prepare four inputs before work begins:
- A route inventory listing every externally reachable path, its upstream service, the data it carries and the consumers that call it.
- Access to the identity provider, including the client registrations needed for the openid-connect plugin, such as Keycloak, Microsoft Entra ID or Okta, and a named owner who can approve changes.
- Log destinations, retention requirements and the people who review gateway logs.
- Your change management process for gateway configuration, including who approves a route change and where that approval is recorded.
Missing any of these usually stretches the timeline more than the technical work does.
Does a SOC 2 Type 1 or Type 2 report change the gateway work?
The configuration work is similar, but the evidence work differs. A Type 1 report covers the system description and whether controls are suitably designed as of a specific date, so the gateway needs to be configured and documented at that date. A Type 2 report adds an opinion on operating effectiveness over a period, so the controls must run consistently throughout that period and the auditor will sample evidence from across it. For a Type 2, plan for log retention, access review records and change tickets to exist for the whole observation window, and confirm the period with your auditor before setting the evidence schedule.
What does the 2026 AICPA attestation standards proposal mean for this work?
The AICPA Auditing Standards Board exposed proposed revisions to its baseline attestation standards in February 2026. According to the Journal of Accountancy, if adopted, the revisions would apply to engagements beginning on or after June 15, 2029. The proposal does not change the Trust Services Criteria controls described on this page. It may change how service auditors document engagements and obtain representations from management. Ask your auditor which standard will govern your examination and when, and check the proposal's current status before planning evidence collection beyond that date.
What does DeployOpen cover in a SOC 2 boundary controls engagement?
DeployOpen plans, implements, configures and documents self-hosted open-source platforms inside your own infrastructure, which includes gateway routes, authentication and restriction configuration, log routing and the documentation that supports your control set. DeployOpen also runs security testing that can check the boundary. DeployOpen prepares systems, controls and evidence for an assessment but does not issue SOC 2 reports, attestations or certifications. The independent CPA firm performing your examination makes that determination, so confirm the evidence format with your auditor before the engagement is scoped.
How DeployOpen scopes and delivers SOC 2 boundary configuration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Apache APISIX as the gateway at your system boundary. We prepare the gateway configuration and the evidence that supports SOC 2 criteria CC6.6, CC6.7 and CC7.2, while the independent service auditor performs the examination and issues any report.
How we scope
- Written scope lists every external route, consumer group and authentication method the gateway must enforce.
- Scope names the IP restriction, rate limiting and TLS requirements for each exposed API and admin path.
- Scope states which logs, configuration exports and monitoring alerts will be produced as evidence for the auditor.
How we build
- We configure routes, authentication plugins and restrictions in version-controlled configuration that your change process can review.
- We test that unauthenticated and out-of-policy requests are rejected, and record the results for the evidence file.
- We set up alerting on anomalous API traffic and document how alerts are triaged and escalated to your security team.
How we hand over
- You receive a system description of the gateway, its deployment mode and its boundary controls, prepared for your SOC 2 description.
- Runbooks cover configuration change steps, Admin API access, certificate rotation and log retention.
- Handover includes a control-to-evidence map showing where each criterion's evidence is stored and who owns it.
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 are available as a retainer.
- Ask your auditor early which evidence samples they expect, since a Type 2 report covers operation over a period.
