Moving past the proxy with identity-first access

Ask most security engineers how their teams were brokering access into AWS, Azure, or GCP in 2015, and you’ll usually get the same answer: a proxy or bastion host, maybe polished up with a slick interface. It was a familiar pattern. Put a jump point in front of your cloud resources, tunnel your engineers through it, and call it “controlled access.” It felt safe. It was relatively straightforward. It was even a little comforting in its simplicity. Like locking the front door of your house and assuming the rest of the property will take care of itself.

The problem, of course, is that cloud security no longer works like that. The front door isn’t where attackers get in anymore. The real breaches almost always happen through identity: compromised tokens, over-privileged roles, forgotten service accounts, and sprawling entitlements nobody has looked at in years. If you’re still only thinking about tunnels, you’re defending the hallway when the burglars are rooting around in the garage.

The Proxy Comfort Zone

There’s a reason proxy-based approaches caught on. They’re reasonably easy to deploy, relatively simple for engineers to use, and they create the same nice, clean on-premise audit log of who walked through the front gate. If you’ve got a legacy estate full of SSH, RDP, and a few finicky databases, a proxy can be useful. It goes some way to standardize the mess.

But proxies are at best a partial solution. They can show you what someone did with a virutal machine or database while using them, but it completely circumvents the extensive audit logging inherent to the cloud platforms. They give the illusion of control, while the real risks, like what an unused admin user can do from the console, the API key rotting in a repository, and the contractor account nobody remembered to disable, quietly rack up in the background.

That’s not malicious neglect; it’s structural. Proxies simply weren’t built to solve cloud identity risk. They were designed to solve network access, and the cloud is no longer a network problem. It’s an identity one.

Working with the Grain of the Cloud

The alternative is to stop skirting around the edges of cloud security and start working inside it. Every major provider (AWS, Azure/Entra, GCP, Okta) has its own IAM fabric. That’s where permissions live, that’s where privileges accumulate, and that’s where attackers go looking for mistakes. If you want to reduce risk, you don’t wrap the cloud in another layer of complexity. You plug directly into that fabric, see everything that’s been granted, and start tightening it up.

When access is managed natively, via the provider’s own APIs and logging, you’re not just recording who asked for a tunnel. You’re recording who had what rights, when, and why, in the systems that matter. You’re shrinking the sprawl of entitlements instead of routing around them. And when auditors come knocking, you can show them a single chain of evidence inside CloudTrail, Azure Activity Logs, or GCP Audit Logs. No parallel paper trails. No explanations about “well, the proxy says…” Just native proof of least privilege.

From Standing Privileges to Just-in-Time

One of the biggest mindset shifts here is moving from standing privileges to just-in-time access. In a proxy world, once you’ve been blessed with a role or tunnel, you probably keep it. The session may expire, but the entitlement lingers in the background, waiting for the wrong token or the wrong person to stumble across it.

In an identity-first world, access is ephemeral by design. Need to touch a production database? Request the privilege. Get it approved. Use it. Watch it vanish the moment the task is done. There’s no S3:* role sitting there gathering dust, no broad GCP project-level rights hanging around “just in case.” The attack surface actually shrinks because there’s less standing access to exploit.

This doesn’t slow anyone down. With automation, pre-defined packs of permissions, and chat-based approvals, the request can take seconds. The engineer still gets what they need. But each request is a reminder: this is sensitive, this is temporary, this is a responsibility, not a birthright. It quietly rewires culture as much as it reduces risk.

The Scale Problem

Another difference becomes obvious the moment you try to scale. A proxy will manage a set of bastions and clusters, but trying to extend it across multiple cloud providers, SaaS applications, and hundreds of service accounts creates seams that begin to split.

Identity-first access control doesn’t blink at that scale. Because it’s working with the provider’s own IAM fabric, it can see across AWS, Azure, GCP, and beyond. It spots the zombie accounts, the unused roles, the long-forgotten contractor entitlements. It’s not about securing a few tunnels. It’s about rationalizing identity at cloud scale.

A Better Risk Story

And that’s what makes this approach more than just another shiny tool in the stack. It changes the risk story. A proxy can reduce the danger of unmanaged SSH and RDP, but it leaves the IAM sprawl untouched. An identity-first model, on the other hand, actually rewires the environment so there are fewer privileges, fewer forgotten accounts, and fewer ways for attackers to get leverage.

In breach after breach, identity is the weak point. Attackers don’t brute-force your bastion host anymore; they phish a user, grab a stale token, or exploit an over-permissioned service account. If your model of access control doesn’t directly address those risks, you’re fighting yesterday’s battle.

Moving Past the Proxy

None of this is to say proxies have no place. If you’re managing legacy systems or Kubernetes clusters in your data center, they can be invaluable. But if your estate is mostly cloud, and for most modern teams, it is, the bigger problem isn’t getting people in. It’s managing what they can do once they’re there, and making sure that access doesn’t linger longer than it should.

Identity-first access isn’t as simple as putting up another gate. It’s more fundamental. It means accepting that the control plane is no longer a network hop; it’s the IAM system itself. Work with it directly, and you reduce risk at the root. Work around it, and you’re just adding more layers without tackling the sprawl.

At some point, every organization outgrows its proxy comfort zone, and tunnelling is for gophers. When you’re ready to actually shrink the attack surface instead of routing through it, the path forward means getting inside the cloud, living in its IAM, and making least privilege and compliance with international cybersecurity standards more than a checkbox.