The IETF's RFC 8705 defines mutual TLS for OAuth client authentication and for certificate-bound access tokens. Those mechanisms answer different questions. The first can authenticate an OAuth client to an authorization server; the second lets a resource server check that a presented token belongs to the client certificate used on the connection. An API can implement one without the other, and neither replaces the application's authorization rules for tenants, objects or transactions.
Quick answer. An mTLS API pentest should cover both certificate directions, the actual verifier and authentication method at every TLS termination point, token-to-certificate binding where OAuth uses it, the configured revocation and rotation policy, and business authorization after the handshake succeeds. Scope the API gateway, authorization server, resource server and representative partner clients together. Stingrai's human-led web and API testers can test these boundaries with approved certificates and tenant accounts, then report each accepted and rejected path with retest evidence.
This is a purchasing guide for B2B API owners, financial technology teams and enterprise integration architects. It translates standards into a scope and deliverable list a procurement team can put in a statement of work. It does not claim that RFC 8705 or NIST mandates Stingrai's proposed test matrix word for word.
First decide what mTLS does in your architecture
A generic requirement saying “the API uses mTLS” conceals several possible designs. A gateway may request a client certificate and pass a verified identity upstream. An OAuth authorization server may use the certificate to authenticate a confidential client. A resource server may require the same certificate when a certificate-bound token is presented. Or mTLS may only protect transport between two internal services, with bearer tokens used elsewhere.
RFC 8705 distinguishes PKI client authentication, which validates an issuer chain and matches a registered subject, from self-signed certificate authentication, which matches a registered certificate without validating its issuer chain. A resource server that uses a certificate-bound token may check possession and token binding without validating the client's issuing CA chain. Revocation checking for the PKI method is a deployment decision. Record which method each component actually uses before choosing a negative test.
Draw the path from partner client to gateway to authorization server to resource server, and mark each TLS termination. For each leg, record:
Which component verifies the server certificate and which trust store it reads.
Which component checks the client certificate, whether it validates a PKI issuer chain or matches a registered certificate, and whether it passes a verified identity downstream.
Whether the OAuth token is bound to the certificate, and which component enforces that binding.
Which application layer decides the partner, tenant, object and function permissions.
Where the configured revocation or deregistration, expiry, renewal and emergency replacement controls are processed.
Figure 1: Five independently testable layers for mTLS API assessments, derived from the OAuth mTLS standard, federal TLS guidance and API authorization risks. Source: IETF RFC 8705, NIST SP 800-52 Rev. 2 and OWASP API Security Top 10 2023.
A certificate valid for one purpose should not automatically become a credential for another. For a PKI method, the test scope needs the accepted issuers, subject or SAN mapping rules and extended key usage policy. For a registered-certificate method, it needs the registration and matching rules. In either case, a reviewer should be able to point to where the gateway establishes the identity and how the upstream service knows it came from a trusted gateway rather than an untrusted header.
The test matrix a buyer should request
Boundary | Approved negative case | Evidence to request |
|---|---|---|
Client verifies server | A safe test endpoint presents an untrusted or wrong-name certificate. | Client rejects the connection in its real runtime and logs a verification failure. |
Authorization server authenticates client | For PKI authentication, present a certificate with an untrusted issuer or wrong registered subject; test revocation only if policy requires it. For the self-signed method, present a certificate that was not registered for that client. | The authorization server rejects the client under its configured method; issuer policy or registered-certificate matching is documented. |
TLS termination | A test request tries to reach an origin without the trusted gateway path. | Origin cannot be reached or cannot accept an unverified identity claim. |
OAuth token binding | A test token bound to certificate A is presented with certificate B. | Resource server rejects the mismatch where certificate-bound tokens are configured. |
Tenant and function authorization | A valid partner certificate and token request another tenant's object or an ungranted operation. | API returns a denial and no protected data or side effect crosses the boundary. |
Certificate lifecycle | Revoke a PKI certificate where revocation checking is configured, or remove or rotate a registered certificate in the controlled environment. | The relevant verifier or registration state changes within the documented window; the old identity loses access under that policy. |
The matrix uses authorized test identities and objects. It is not a request to create forged public certificates or attack a third-party partner. The tester and owner agree on safe negative cases before the engagement, including any rate, availability and logging limits.
Certificate path, revocation and trust anchors
NIST SP 800-52 Rev. 2, section 3.5 tells US federal TLS server operators to validate a client-certificate path and revocation status. It also advises a minimum necessary set of trust anchors for client authentication. Those are useful questions for an enterprise API using PKI client authentication even when the organization is not federally bound by that publication: can the gateway explain why it trusts each client CA, and does it reject a certificate that its policy says is invalid? A registered self-signed OAuth client or a resource server checking only token possession needs a different acceptance test.
Test the application's deployed verifier, not a developer laptop's curl command. A proxy, service mesh or language runtime can use a different bundle. The October 2026 eMudhra CA incident illustrates why a browser's rapid distrust update does not establish the state of a custom API trust store. Cloudflare's incident guidance warns that an SDK update alone may not change the library that verifies the certificate.
OAuth binding and replay resistance
RFC 8705 permits certificate-bound access tokens and mTLS client authentication to be deployed separately. Therefore, ask the owner which clients receive bound tokens and which endpoints enforce them. A test should compare the expected claim or introspection result with the certificate actually used at the resource-server connection. If the architecture re-terminates TLS at an intermediary, the SOW must say how the binding survives that hop and which component is trusted to assert it.
Do not let “we use mTLS” become an unsupported claim that stolen bearer tokens are unusable everywhere. The binding is effective only where token issuance and resource access are configured and checked consistently. Record exceptions, legacy clients and fallback paths.
Business authorization remains a separate test
The OWASP API Security Top 10 2023 puts broken object-level authorization and broken function-level authorization among the API risks. A perfectly authenticated partner can still be allowed too much. Give testers two or more partner or tenant identities, objects owned by each and representative write operations. A valuable finding demonstrates the exact authorization boundary crossed and a safe remediation path, not merely that a TLS handshake worked.
The scoping worksheet for procurement
A quote will be more accurate if you provide a boundary inventory rather than only an endpoint count. Include production and nonproduction endpoints, API gateways, authorization servers, mobile or machine clients, certificate issuers, cloud accounts, regions, partner groups, OAuth grant types, scopes, tenant roles and approval contacts. State whether the tester may inspect configuration and code. Provide sanitized OpenAPI definitions and test data where available.
Ask the vendor to break the work into these deliverables:
An architecture map showing TLS termination and identity propagation for each representative integration.
A written certificate and OAuth test matrix, including accepted and rejected cases and the environments used.
Authenticated API authorization testing across representative partner and tenant roles.
Findings with proof, owner, business impact and remediation priority in language suitable for engineers and risk owners.
A retest that demonstrates the fixed boundary and records any residual risk.
Stingrai's published web application packages cover one web application and associated APIs. More complex multi-application, partner or network scopes are custom quoted. Check pricing, or use Get a Quote with the worksheet above. Stingrai is a Toronto-founded, CREST-accredited penetration testing services company. Human-led engagements assign two named penetration testers from a team holding OSCE³, OSWE, OSEP and CREST CRT certifications, provide confirmed findings during the test and include retesting.
A web application penetration test is the core engagement for API authorization and business logic. Add cloud penetration testing when gateway policies, secret stores and workload identities are in scope. The FAPI 2.0 open-banking scope guide has further context where financial API profiles apply.
Red flags in an mTLS testing proposal
A proposal that says only “scan TLS configuration” is too narrow for an API that uses certificates as identity. It may check protocols and ciphers but never test a wrong client certificate or another tenant's object. Likewise, a quote that promises to test every partner integration without identifying certificates, test accounts, environments and authorization rules is not yet a testable scope.
Ask how the team will handle certificate issuance safely, how it will avoid disrupting a real partner, and how it will prove a negative case. Ask whether the report will distinguish a gateway policy error from an application authorization defect, and whether the retest will cover the same path. Those details let the buyer compare two quotes on evidence, not only on price.
Frequently Asked Questions
What should an mTLS API penetration test cover?
It should cover server certificate validation; the configured PKI or registered-certificate client authentication method; revocation or deregistration and rotation as applicable; TLS termination; OAuth certificate binding where configured; and tenant and function authorization after authentication. The exact boundary list depends on the deployed architecture.
Is mTLS alone enough to stop API authorization flaws?
No. mTLS can authenticate a peer, while the application still needs to decide what that peer may read or change. A valid certificate does not grant access to every tenant or object.
Are OAuth mTLS client authentication and certificate-bound tokens the same thing?
No. RFC 8705 describes them as complementary but distinct mechanisms. The authorization server can use a certificate to authenticate a client, while the resource server separately checks that a presented bound token belongs to the certificate on its connection.
Should the test use production certificates?
Use approved, controlled test certificates and identities wherever possible. Production testing may be appropriate for carefully authorized, non-disruptive checks, but the rules of engagement should name the endpoints, accounts and permitted negative cases before work starts.
How should we compare mTLS API pentest quotes?
Compare the boundary inventory, representative client and tenant roles, accepted and rejected cases, configuration access, reporting evidence and included retest. An endpoint count or a TLS scanner result alone does not show the depth of the assessment.
Related reading
References
IETF, RFC 8705, OAuth mTLS client authentication and certificate-bound access tokens.
NIST, SP 800-52 Rev. 2, Guidelines for TLS Implementations, section 3.5.
Cloudflare, eMudhra certificate compromise response, 20 October 2026.
Talk to Stingrai
Stingrai can scope human-led testing of the certificates, OAuth clients, API roles and cloud boundaries that define your mTLS integration. Get a Quote or book a free discovery call to review the worksheet with our team.
