Zero Trust Without Friction: Rethinking How We Secure Partner Integrations

Most B2B integrations still rely on IP allow lists, and for cloud-native systems, that’s becoming a liability. The workflow is familiar: a service runs behind a NAT gateway, it exposes a static egress IP, the partner adds it to their firewall, and traffic flows. Simple. Understandable. Widely accepted by every security team that’s reviewed it.

And in a lot of environments, it works fine.

But in cloud-native systems where workloads are ephemeral, architectures span accounts and regions, and the only constant is change, this model is starting to show cracks.

The Default Nobody Questions

IP-based security has been the standard for B2B integrations for a long time, and for good reason. It maps to how enterprise security teams think about trust: control the network perimeter, know what’s coming in and where it’s going, restrict everything else. That mental model made sense when infrastructure was static and owned outright.

What’s changed is the infrastructure itself. Cloud-native systems don’t stay put. Workloads migrate across availability zones. Services get replicated across regions for redundancy. Disaster recovery strategies kick in and cut over to different endpoints. The network layer has become something you configure, not something you own, and IP addresses are increasingly incidental to where your application actually runs.

We’re still using a perimeter model in a perimeter-less world.

How We Actually Build This Today

To make this concrete: at HCE, a core integration workflow pulls student data from Slate, runs it through a SAI ETL pipeline, and pushes results back to partner institutions via REST APIs. The model is strictly outbound; we initiate, partners receive.

The current security posture for that outbound traffic looks like most enterprise implementations: a NAT Gateway with an Elastic IP, scoped per region, so partners can allow-list a known, stable address. It’s a clean setup. It handles cross-region and cross-account considerations reasonably well when you plan for them. It works, until you try to scale it.

It also introduces structural debt that only shows up when you try to scale or fail over.

Where the Cracks Appear

The pressure doesn’t show up immediately; it accumulates.

Add a second AWS region for redundancy and you’ve doubled the IPs your partners track. Build a real failover strategy and you’ll need to coordinate IP updates with every partner before you can cut over. Expand into additional accounts and the coordination surface grows again. Each partner institution is independently maintaining a list of your infrastructure details, and every time your infrastructure changes, even for reasons that have nothing to do with security, that list needs to change too.

There’s also a subtler exposure: static IPs are predictable targets. In a model where trust is tied to an address, that address becomes meaningful to attackers in ways that ephemeral workloads aren’t. You’ve created a concentrated ingress point precisely because you need your partners to know where you are.

The natural friction there doesn’t go away; it just shows up as tickets, coordination calls, and incidents.

At scale, this stops being a security model and starts being a coordination problem.

The Actual Problem: Infrastructure-Based Trust

Step back from the implementation for a moment. The root issue isn’t operational overhead or static IPs specifically. It’s the underlying model: trust is based on where traffic comes from.

That only holds when “where” is stable and meaningful. It made sense when a data center’s fixed egress IP represented a known, controlled environment. It makes less sense when that same address might represent a Lambda function running in us-east-1 today and a failover in us-west-2 tomorrow.

In modern cloud architecture, network location is an artifact of deployment configuration, not a proxy for identity. And yet that’s what we’re asking partners to stake their security posture on.

IP-based security assumes stability where none exists.

What Zero Trust Actually Means Here

Zero trust is an overloaded term at this point, so it’s worth grounding it. The core principle is simple: don’t assume trust based on network location. Instead, establish trust based on identity, policy, and context, and verify continuously.

In a B2B integration context, that means shifting from “I trust this traffic because it came from this IP” to “I trust this service because it authenticated as this identity, under this policy, for this resource.” Every interaction is authorized explicitly, regardless of where on the network it originates.

For organizations like HCE, where integrations carry sensitive financial aid data and operate under FERPA and related requirements, this model is more aligned with the underlying security requirements. An IP address doesn’t prove who is accessing a student record; a cryptographic identity does. Least privilege, RBAC, and fine-grained access controls are easier to enforce when identity is the control plane rather than network topology.

That shift becomes especially consequential when applied to what partners are expected to do.

Abstracting Security Away from Your Partners

Here’s what most zero trust discussions miss from a B2B lens: the burden isn’t symmetric. In the traditional model, partners carry real operational load. They configure firewalls, maintain your IP list, coordinate with their security team on every change, and validate that the address they received is actually yours. They’re doing infrastructure management on your behalf, indefinitely.

Zero trust creates an opportunity to change that relationship.

The model that’s inspired a lot of thinking in this space, including Zscaler’s private access architecture (ZPA), which brokers authenticated connections between services without exposing them directly, flips the connection model. Instead of your service announcing itself via a known egress IP, your service connects outbound to a secure broker. Your partner connects to that same broker via an authenticated, policy-controlled endpoint. Traffic flows through the broker; neither side exposes a direct network path to the other.

The implication is significant: your partners no longer need to manage your infrastructure details. They don’t need to know your IPs. They don’t need to update firewall rules when you add a region. They don’t need to track which of your AWS accounts is in scope for a given integration. The broker handles that, and identity handles the trust.

What This Looks Like Architecturally

Keeping this conceptual, because the right implementation depends on your stack and your partners’ constraints, the model looks roughly like this:

Your service (a Lambda function inside a VPC, for example) establishes an outbound-only connection to a secure access layer. No inbound ports. No exposed endpoints. The connection is authenticated at the service level using identity credentials, not network location.

Your partner connects to that same layer via an authenticated endpoint they can reach without configuring your specific infrastructure. The access layer enforces policy: this partner can reach this API endpoint, under these conditions, with this level of access.

What disappears from your partner’s side: firewall changes, IP allow-listing, and infrastructure tracking. What remains: authentication and policy compliance, which is where the security conversation should have been the whole time.

The Strategic Value Isn’t Just Security

This is the part that tends to get lost in zero trust discussions, which usually stay in the security lane. The real leverage here is partnership friction.

Consider what onboarding a new partner actually costs under the current model. There’s the IP coordination. The firewall change request on their end. The delay while their security team reviews it. The follow-up when something doesn’t connect. The repeat of that entire cycle when you add a region or rotate infrastructure.

Under a zero trust broker model, new partner onboarding becomes: provision an identity, set a policy, share an endpoint. Most enterprise partners already speak this language; OIDC and SAML are table stakes at this point. No infrastructure dependencies on either side. No coordination tax.

That’s not just a security improvement; it’s a competitive advantage for organizations building integrations at scale. The teams that can abstract this complexity away from their partners will close integrations faster, with fewer barriers, and with a security model that’s easier to audit and evolve over time.

The real opportunity isn’t just better security; it’s making secure integrations easier to adopt.

The Honest Tradeoffs

Broker-based architectures introduce a third-party dependency in the critical path. If the broker has an outage, integrations have an outage. That’s a different kind of operational risk than IP-based models carry, and it needs to be accounted for in reliability design. Cost models for managed access platforms can also be non-trivial at scale, and for simpler integrations with stable partners and low data sensitivity, the overhead may not be worth it.

The framing worth pushing back on is treating this as binary. IP allow lists and zero trust models aren’t mutually exclusive during a transition. Most mature architectures will evolve, not replace. The right question isn’t “should we switch to zero trust?” but “where is the IP model creating friction we shouldn’t accept?”

Where B2B Architecture Is Heading

IP allow lists are a legacy pattern. They emerged from a reasonable mental model of trust, applied to infrastructure that was stable enough to support it. In cloud-native, multi-region, multi-account environments, that stability assumption is gone.

The architectural direction is clear. Workloads are ephemeral. Networks are configuration. Identity is the only reliable constant. The question isn’t whether trust moves up the stack from infrastructure to identity; it’s when, and how gracefully.

For B2B integrations specifically, that transition carries a compounding benefit: you can reduce friction for partners at the same time you’re strengthening your own security posture. That combination, less friction, better controls, simpler operations, is the case that lands in architectural review meetings and partnership conversations alike.

As B2B systems become more distributed, trust needs to move up the stack, from infrastructure to identity. The organizations that get there first won’t just have better security. They’ll have better partnerships.