A Practical Azure Front Door Mutual TLS Playbook for B2B APIs

In this blog post A Practical Azure Front Door Mutual TLS Playbook for B2B APIs we will explain how to stop unknown systems from reaching partner APIs, where mutual TLS fits, and how to introduce it without breaking important integrations.

Many B2B APIs are protected by an API key, a password, or a list of approved IP addresses. That may have worked when there were three partners, but it becomes difficult to manage when suppliers change networks, credentials are shared, and nobody is certain which systems still need access.

Mutual TLS, usually shortened to mTLS, addresses this problem by requiring both sides of a connection to prove their identity. The API presents its normal security certificate, while the connecting partner must also present a valid client certificate before its request is accepted.

What Azure Front Door mutual TLS actually does

Azure Front Door is Microsoft’s global entry point for internet-facing applications and APIs. It can route requests to the closest healthy service, inspect traffic for attacks, and prevent partners from connecting directly to the underlying application.

With mutual TLS enabled, Azure Front Door checks the partner’s client certificate during the initial encrypted connection. Requests without an acceptable certificate can be rejected at Microsoft’s network edge, before they consume capacity or reach your API.

This creates a useful front gate for B2B services. Instead of asking only, “Does this caller know a password?”, you can also ask, “Is this an approved system holding a certificate that we issued or trust?”

At the time of writing in August 2026, Azure Front Door mutual TLS is in public preview and is available with Azure Front Door Premium. Preview services require additional testing and risk review before they are used for critical production workloads.

Why an API key is usually not enough

API keys are easy to copy, email, place in an insecure configuration file, or accidentally expose in application logs. When several partners share the same key, revoking one compromised connection can interrupt everyone.

IP address restrictions have similar limitations. Partners change internet providers, move workloads between data centres, and adopt cloud platforms where outbound addresses may not remain fixed.

Mutual TLS provides a stronger system identity because the partner must possess the certificate’s private key. This private key is the secret component used to prove that the connecting system owns the certificate.

However, mTLS is not a complete security strategy. It authenticates the connecting system, but your API must still decide what that system is allowed to do. OAuth tokens, application permissions, rate limits and business rules should remain in place.

A sensible architecture for B2B APIs

A practical design places Azure Front Door Premium in front of Azure API Management, which publishes and controls APIs, or directly in front of an Azure-hosted application. The request path looks like this:

Partner system with client certificate
 |
 v
Azure Front Door Premium with mTLS
 |
 +-- Web Application Firewall inspection
 +-- Certificate validation
 +-- Routing and availability checks
 |
 v
Azure API Management or private application
 |
 v
Business systems and data

The Web Application Firewall, or WAF, inspects web requests for common attacks. It performs a different job from mTLS: the certificate establishes who is connecting, while the WAF checks whether the request itself appears dangerous.

Where possible, the origin application should use Azure Private Link, which allows Front Door to reach the service through a private Azure connection rather than exposing it directly to the internet. If Private Link is not suitable, restrict the origin so it accepts requests only from your Front Door deployment.

This last step matters because Azure Front Door ends the original encrypted connection and creates a separate encrypted connection to the origin. Certificate details can be passed in the X-Azure-ClientCertificate header, but your application should never trust that header if attackers can bypass Front Door and reach the origin directly.

A five-step rollout playbook

1. Identify the connections that justify mTLS

Start with APIs that exchange sensitive information, trigger financial transactions, support important suppliers, or allow machine-to-machine access without a person signing in.

Document every partner, application owner, certificate contact and expected transaction pattern. This often uncovers old integrations that are still running under shared credentials nobody wants to change.

2. Create a certificate trust model

Decide which certificate authorities, or organisations that issue and verify certificates, Azure Front Door should trust. A private certificate authority gives your organisation tighter control, while an approved public provider may simplify some partner arrangements.

Give each partner, and ideally each production system, its own certificate. Do not issue one certificate to five suppliers simply because it is faster. Individual certificates let you remove one compromised partner without disrupting the rest.

Define who issues certificates, how private keys must be stored, when certificates expire, and how emergency revocation works. Certificate renewal should be treated as a managed business process, not a calendar reminder belonging to one engineer.

3. Use a dedicated API hostname

Place certificate-protected services on a dedicated hostname such as partner-api.example.com. Avoid enabling mandatory mTLS on a shared domain that also serves public websites, mobile applications or integrations that cannot present certificates.

A separate hostname makes testing, partner migration and rollback considerably safer. It also creates a clear boundary between public traffic and trusted B2B connections.

4. Configure validation and layered controls

For a new B2B API, the normal target should be “client certificate required and validated”. In this mode, Azure Front Door checks that a certificate is present and validates items such as its trust chain, expiry and revocation status.

Optional validation can support a staged migration, where certified and non-certified partners temporarily share an endpoint. Modes that leave validation to the origin should only be used when the backend already has well-tested certificate validation logic.

Keep HTTPS encryption from Front Door to the origin, enable WAF policies, apply API rate limits, and retain token-based permissions. For AI and agent endpoints, these controls should sit alongside the safeguards covered in our guide to securing Azure AI services.

5. Test failure before testing success

Do not test only with a valid certificate. Confirm that requests fail when the certificate is missing, expired, revoked, issued by an unknown authority, or presented for the wrong identity.

# Expected to succeed with an approved certificate
curl --cert partner-client.pem \
 --key partner-client.key \
 https://partner-api.example.com/orders

# Expected to fail when a certificate is required
curl https://partner-api.example.com/orders

Run these tests from outside your corporate network so they reflect a genuine partner connection. Also test certificate renewal and rollback before the first production expiry date arrives.

What this looks like in a real business

Consider a 200-person distributor exchanging orders with eight logistics and retail partners. Its original API used shared credentials and approved IP addresses, creating delays whenever a partner changed cloud providers.

The company moves partner traffic to a dedicated Front Door hostname and issues a separate certificate for each integration. One partner’s certificate can now be revoked without resetting credentials or firewall rules for the other seven.

The business outcome is fewer emergency changes, clearer ownership and a smaller chance that a stolen credential will provide direct API access. Operations teams also gain a reliable record of which partner system attempted each connection.

Monitoring and governance cannot be optional

Send Azure Front Door diagnostic and WAF logs to your central monitoring platform. Alert on sudden increases in rejected connections, repeated certificate failures, unusual traffic volumes and attempts to bypass expected API paths.

Review certificate ownership and expiry dates as part of regular access reviews. For Australian organisations following Essential 8, the Australian government’s baseline cybersecurity framework, mTLS can support stronger access control and monitoring but does not create compliance on its own.

The same identity questions also apply when AI agents communicate across company boundaries. If your roadmap includes agent-to-agent integrations, our guide to cross-platform multi-agent workflows explains the wider governance decisions.

Make the front gate part of a wider security plan

Azure Front Door mutual TLS can give B2B APIs a much stronger front gate. The value comes from combining it with individual partner certificates, private origins, WAF inspection, API permissions, monitoring and a tested renewal process.

CloudProInc brings more than 20 years of enterprise IT experience to these decisions. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations design practical Azure, API and cybersecurity controls without turning the project into a giant consulting exercise.

If you are unsure whether your partner APIs are properly protected, or whether mutual TLS is ready for your production environment, we are happy to review the current setup and highlight the gaps — no strings attached.