Why 'Partial Support' on Your API Gateway Is Costing You More Than You Think
Your gateway vendor says it supports RBAC, audit logging, and mTLS. What they don't say is that RBAC doesn't extend to the portal, audit logs miss admin operations, and mTLS only works on specific route types. Partial support has a price.
- api-management
- governance
- enterprise
- security
"Does your gateway support RBAC?" Yes. "Does it support audit logging?" Yes. "Does it support mTLS?" Yes.
These are the right questions. The problem is that a vendor answering "yes" to all three can still leave you with a gateway that does not enforce access control in the developer portal, does not log admin-plane operations, and requires a separate configuration layer to make mTLS work on anything other than simple proxy routes.
Partial support is a specific, expensive failure mode. It is expensive because it only appears after procurement — when your engineering team is building against it, your security team is auditing it, and your compliance team is trying to produce evidence that does not exist.
What "partial support" looks like in practice
RBAC that stops at the gateway. Your gateway enforces role-based access on API traffic — different clients see different endpoints based on their assigned products and scopes. But your developer portal, managed by the same vendor, has a separate permission model. A partner with a standard-tier gateway credential can browse documentation for premium-tier products in the portal. A sandbox credential can try endpoints in the portal's interactive console that it is not permitted to call in production.
The gateway enforces RBAC. The portal does not. The result is security theater: access control that works in the path your security team tested and fails in the path your partners actually use.
Audit logs with gaps. Your gateway logs every API call — method, endpoint, response code, client identity, timestamp. The vendor says it is "compliance-ready." What the audit log does not capture: changes to gateway configuration (new routes added, rate limits changed, access policies updated), administrative actions (credentials issued, products assigned, partner access revoked), and developer portal operations (who logged in, what documentation they accessed, what try-it calls they made).
When your compliance team asks for a complete audit trail — not just API calls, but all events that could affect the security posture of your API estate — the gateway provides half the picture. The other half requires digging into server logs, admin console history, or a third-party SIEM integration that may or may not have been capturing the right events.
mTLS that works on simple routes. Your gateway supports mTLS. It validates client certificates on inbound connections and uses certificate identity for access control. But mTLS validation only works on standard proxy routes — it does not apply to workflow routes that call multiple backends, it does not propagate the certificate identity into the audit log in a useful form, and it requires separate configuration for each route rather than a platform-level policy.
The result: your mTLS deployment covers 60% of your API surface — the simple routes that were easy to configure. The other 40% — the complex workflows, the legacy integrations, the recently added endpoints — either have mTLS disabled or have it configured inconsistently because the engineering team ran out of time to work through the edge cases.
The costs that accumulate from partial support
Custom code to fill the gaps. When the gateway does not enforce RBAC in the portal, engineering builds a custom middleware layer to do it. When the audit log misses admin operations, someone writes a log aggregation pipeline to capture them from a separate source. When mTLS does not propagate certificate identity consistently, a custom header injection scheme is added to carry it through.
These are not one-time engineering investments. They are ongoing maintenance burdens. Every gateway update is a risk that the custom layer breaks. Every new feature the vendor adds may or may not interact correctly with the custom workaround. The engineering team that built it leaves, and the next team inherits code that exists to compensate for a vendor's partial implementation.
Compliance evidence that does not match the claim. You tell your auditor: "We have RBAC, audit logging, and mTLS." Your auditor asks to see evidence. The RBAC evidence covers gateway traffic but not portal access. The audit log has a six-month gap from before you built the custom aggregation pipeline. The mTLS configuration is inconsistent across routes.
The gap between what you claimed and what you can demonstrate is a compliance finding. The cost is not just the finding itself — it is the remediation project, the re-audit, and the period of elevated scrutiny that follows.
Operational complexity that scales with your API estate. Partial support forces workarounds. Workarounds create operational debt. Operational debt compounds as the API estate grows. At 10 APIs, the workarounds are manageable. At 100 APIs, they are a fragile system that the ops team is afraid to touch. At 500 APIs, they are the reason your change failure rate is high and your incident response is slow.
How to evaluate for partial support before you buy
The questions that reveal partial support are not "do you support X?" — they are "where does X apply, and where does it not?"
For RBAC: Does RBAC apply to developer portal access and try-it calls, or only to gateway traffic? Can the same access control policy be expressed once and enforced consistently across both surfaces?
For audit logging: Does the audit log capture admin-plane operations — configuration changes, credential lifecycle events, policy updates — or only data-plane API calls? Is there a single log stream, or do we need to correlate multiple sources?
For mTLS: Does mTLS apply to all route types — simple proxies, workflow routes, routes with request transformation — or only to specific configurations? Does certificate identity propagate consistently through the audit trail?
For rate limiting: Do rate limits apply to developer portal try-it calls, or only to production API traffic? Can limits be set per-client, or only per-route?
For credential management: Is credential issuance, rotation, and revocation managed through the same system as access control enforcement, or are these in separate tools that need to be kept in sync?
A vendor that can answer all of these clearly, with documentation that matches the answer, is not hiding partial support behind a "yes." A vendor that deflects to "we support X" without specifying where and under what conditions almost certainly has gaps.
The comparison table question
Vendor comparison tables are built to highlight what a product supports. They are not built to show where support is partial, inconsistent, or requires additional configuration to work correctly.
When you see a competitor comparison table — including ours — the right response is to take the cells where a competitor is marked as not supporting something and ask: "Do we need that, and does our current vendor's implementation of the equivalent actually cover our use case?"
The answer is often that the feature you thought you had is the partial version — the one that works in the demo, covers the simple case, and falls short on the edge cases that matter in production.
Zerq is built so that RBAC, audit logging, mTLS, rate limiting, and credential management apply consistently across the gateway, developer portal, and admin plane — not just on the routes that were easy to configure. See the full capabilities or request a demo to test specific scenarios against your compliance and operational requirements before you commit.