API Gateway Security: A Zero Trust Approach

APIs are the connective tissue of modern business. But the openness that makes them useful is also what makes them the most vulnerable part of your stack. Traditional, perimeter-based API security solutions struggle to keep pace in today’s lightning-fast, AI heavy environments. Luckily, there’s a better approach: a Zero Trust model that uses private API gateways, closing the gap without slowing teams down. The mechanics behind it are the same everywhere, but what’s at stake looks different depending on who’s using it, from a SaaS provider protecting proprietary access to a bank meeting a hard regulatory mandate.

Why Are APIs the Top Attack Vector for Cyberattacks?

Most business applications sit behind a private network (MPLS, VPN, or Zero Trust Network Access), but APIs are the exception. By design, they’re exposed to the public internet so distributed clients can reach them.

The problem? The exposure that creates connectivity also creates a security weakness. Each API is basically a unique “snowflake”, constantly evolving through changes to business logic, authentication, and configuration. Traditional “Day 2” defenses like WAFs and API security platforms are good at blocking known threats, but a large share of API attacks are functionally zero-day: they exploit a change that didn’t exist yesterday. Racing to patch a public-facing API against every attacker on the internet is a race defenders often lose…and losing can mean a service outage, data breach, or compromised customer.

This is the core argument in NetFoundry CEO Galeal Zino’s DevOps.com piece, Squaring the Circle: How to Make Public APIs Private, and it sets the stage for a different approach: Zero Trust API Networking.

What Is Zero Trust API Networking?

Zero Trust API Networking rethinks API accessibility from the ground up. Rather than trying to filter traffic after it reaches a public endpoint, it removes the public endpoint entirely, while still letting authorized clients connect with full agility. In practice, this means:

• Eliminating public access. API clients reach the API through private addressing, not a discoverable public domain. There’s nothing for an attacker to scan or interrogate.
• Authenticating identity first. Every connection requires cryptographic identity, continuous authentication, and least-privilege authorization (typically via mTLS) before any data moves.
• Going outbound-only. Instead of opening inbound ports for the world to find, the API server initiates authorized outbound connections into the Zero Trust overlay.

The result: public APIs get the same seclusion as a private network, without giving up the reach and agility that make APIs valuable in the first place.

What Does Zero Trust API Gateway Security Look Like in Practice?

The mechanics stay constant: authenticate identity, eliminate public exposure, go outbound-only. But what changes industry-to-industry are the pressures driving adoption. Below, we’ll go through two common examples.

Software and SaaS: Protecting Proprietary API Access

APIs are the backbone of most software products, so protecting them is directly tied to protecting intellectual property and customer data. Software companies typically combine three practices:

• Secure development. Teams follow the OWASP API Security Top 10 to address the most common API vulnerabilities, paired with regular security assessments as part of their DevOps workflow.
• Zero Trust networking. Implementing Zero Trust principles lets a provider stand up a private API gateway that only authenticated, authorized users can reach, shrinking the attack surface rather than just monitoring it.
• Comprehensive API management. Monitoring, rate limiting, access control, and detailed logging give teams the visibility to confirm API usage stays secure and compliant with industry standards, in production and in development alike.

Real-world example: Intrusion, a NetFoundry customer, built its Zero Trust Network Access solution on the NetFoundry platform as part of a 2023 partnership supporting the U.S. federal government’s Zero Trust cybersecurity standards. At the time, Tony Scott, CEO of Intrusion, tied the move to the federal mandate that the tech industry take more responsibility for protecting the public from cybercriminals rather than leaving that burden on individual users. That argument has only grown more relevant in recent years as Zero Trust requirements have expanded across both government and regulated industries.

Banking: Meeting PSD2 and Regulatory Mandates

Banks sit at the intersection of high attacker interest and heavy regulatory obligation, which makes API gateway security a compliance issue as much as a technical one.

• Regulatory alignment. Regulations like PSD2 in Europe require strong customer authentication and secure open banking APIs. A Zero Trust approach that authenticates and authorizes every request maps directly onto that requirement, vs. bolting compliance on afterward.
• Private API gateways. Shielding APIs from the public internet makes them invisible to unauthorized users, while end-to-end encryption protects data in transit.
• Real-time monitoring. Banks pair this with anomaly detection to catch and respond to suspicious activity before it escalates, treating Zero Trust access controls and monitoring as complementary layers, not substitutes for each other.

Together, these controls mean a bank can meet its regulatory mandate and shrink its attack surface at the same time, rather than treating compliance and security as two separate line items.

Zero Trust: Make APIs Invisible Without Slowing Teams Down

Traditional, perimeter-based API security wasn’t built for how APIs actually behave: public by design, changing constantly, exposed to every attacker on the internet at once. Zero Trust API Networking flips that. It makes APIs invisible to anyone who hasn’t been authenticated, without asking developers to sacrifice the speed and agility that makes them worth building in the first place.

That’s the same principle behind NetFoundry’s approach to API Security: reducing the reachable attack surface by keeping APIs unreachable until identity and authorization are verified, whether you’re a SaaS provider protecting your IP or a bank meeting PSD2 requirements.

If your APIs are still sitting on the public internet waiting to be found, talk to us about what a private, Zero Trust API gateway would look like for your environment.

Frequently Asked Questions

What is API gateway security?

API gateway security refers to the practices and technologies used to protect the entry point through which client applications access backend APIs — including authentication, encryption, and access control. NetFoundry approaches this by removing the API’s public exposure entirely rather than only filtering traffic at the gateway.

What is Zero Trust API Networking

Zero Trust API Networking is an approach that treats every API request as untrusted until it’s authenticated and authorized, regardless of where it originates. At NetFoundry, we implement this using private addressing, mutual TLS identity verification, and outbound-only connections, so APIs stay invisible to anyone who hasn’t already been verified.

Does a private API gateway slow down development or integration?

No — the goal is security without sacrificing agility. Authorized clients connect the same way they always have, typically by adding a small amount of code or a lightweight agent; the difference is invisible to legitimate traffic and only affects unauthorized access attempts.

Is this relevant to compliance requirements like PSD2 or PCI-DSS?

Yes. Regulations like PSD2 require strong customer authentication and secure handling of open banking APIs. A Zero Trust model, where every request is authenticated and authorized before access is granted, aligns naturally with these requirements rather than requiring a separate compliance layer.

How is this different from a traditional API gateway or WAF?

Traditional gateways and WAFs inspect and filter traffic after it reaches a public-facing endpoint. A Zero Trust private API gateway removes the public endpoint altogether, so there’s nothing on the open internet for an attacker to scan, probe, or exploit in the first place.