IAM deployment considerations for an uncertain world

For almost two decades, the story was simple: Everything moves to the cloud, eventually becomes SaaS and on-premise is a museum exhibit you visit on old architecture diagrams. That story isn't wrong. It's just ... paused.

Something's changed, and it's not a technology problem. It's a trust problem.

Organizations aren't rejecting the cloud because it's slow, expensive or hard to use. They're getting nervous about where their data actually lives, who can touch it and what happens if the relationship with a hyperscaler ever goes sideways—geopolitically, contractually or otherwise. This isn't the General Data Protection Regulation (GDPR) conversation anymore. It's bigger than "keep EU data in the EU." It's "keep our data on infrastructure we control, full stop."

So what do you actually do with that? Let's work through the questions I keep hearing, because that's how this conversation always unfolds anyway.

Why are organizations moving away from cloud-first strategies?

A few things converged at once. First, there's the sheer concentration of the hyperscaler market. A handful of companies now sit underneath an enormous share of global digital infrastructure, and boards are starting to ask, "what's our exposure if any one of these becomes unavailable to us, technically or politically?"

Second, sovereignty has become a boardroom word, not just a government one. Regulators across multiple regions are actively pushing "digital sovereignty" requirements that go beyond privacy. They're about jurisdiction, control and the ability to walk away.

Third, and maybe most understated: The cost of being wrong has increased.

A breach, an outage or a forced data-access event isn't an incident report anymore; it's a headline and a shareholder call

None of this means the cloud is bad. It means the question has changed from "how fast can we get there" to "what are we exposed to when we do."

Do I have to give up SaaS to secure my data?

No, and please don't. The realistic answer isn't "abandon SaaS," it's "stop trusting SaaS platforms with the keys to your kingdom by default." There's a difference between using a SaaS application and granting that application unrestricted, standing access to your most sensitive systems and secrets.

The pattern that's emerging looks like this:

Let the SaaS app do what it's good at, like workflow, UX, scale and uptime that someone else manages. Keep the actual credentials, secrets and access decisions under your control, brokered through infrastructure you own. Think of it like a hotel key card: The front desk doesn't hand you a master key to the building. You get a card that opens your room, works only for the dates of your stay, and stops working the moment you check out.

That's access scoped to exactly what you need, for exactly as long as you need it, not a copy of the master key.

What is the role of an enterprise vault in runtime authorization?

This is the question that matters most.

The old model of a vault was basically a really secure filing cabinet: credentials sat in a hardened store, and something (a person, a script, an app) checked one out, often holding that standing access far longer than needed. That model made sense when "access" meant a human logging into a server. It makes much less sense now, when the majority of access requests come from workloads, pipelines, AI agents and services that spin up and disappear in seconds.

Runtime authorization flips the model. Instead of a credential existing and sitting there waiting to be misused, access is granted the instant it's needed, scoped to exactly what's needed and revoked the instant the task is done.

Nothing standing, nothing lingering, nothing to steal.

The vault's job changes. It's no longer just a vault. It's the brokering layer that decides, in real time, whether this identity, at this moment, for this specific action, gets a short-lived credential or a temporary elevation of privilege. That decision engine has to live somewhere you trust completely, because it's effectively the thing deciding who gets to touch what, everywhere, all the time. That's precisely why organizations want it on infrastructure they control.

You can outsource the SaaS front end, but you don't want to outsource the thing making every access decision for your entire environment

And this matters just as much, if not more, for non-human identities (NHI). These are service accounts, API keys or AI agents making autonomous calls into your systems. Not only do they now outnumber human users by a wide margin, but they also don't ask permission the way a person does. A runtime authorization model that treats every one of these as "verify now, grant briefly, revoke automatically" closes off an enormous amount of the standing-access risk that used to just sit there, waiting.

How do I keep my data safe on SaaS platforms I don't fully trust?

This comes down to a few habits, not one silver-bullet product:

• Separate the data plane from the control plane. Let the SaaS platform process and display data. Don't let it be the permanent home for your crown-jewel secrets or the sole decision-maker on who gets access to what.

• Broker, don't hand over. Whatever brokers access, whether a vault, a proxy or a Privileged Access Management (PAM) platform, should sit on infrastructure you own or tightly control, issuing short-lived credentials into the SaaS environment rather than storing long-lived ones inside it.

• Assume every identity might be compromised, human or not. Design access as if the identity requesting it has already been phished, leaked or spoofed. Just-in-time, least-privilege access limits the blast radius even when that assumption turns out to be true.

• Audit like the SaaS vendor is a stranger, because in a sense, they are. Log every access decision on your side of the boundary, not just theirs. You want a record that doesn't depend on their goodwill or their uptime.

None of this is exotic. It's the same zero-trust logic security teams have been preaching for years. It's just finally catching up to the reality of where data sits and who has to answer for it.

Is hybrid infrastructure a retreat from the cloud, or something else?

Something else. Call it "sovereign hybrid," call it "trust-aware architecture," call it whatever your next slide deck needs it to be called. The underlying shift is the same. Organizations aren't running back to the data center because cloud failed them technically. They're redrawing the boundary between "where convenience lives" and "where control lives," and increasingly deciding those don't have to be the same place.

The winners in the next phase won't be the companies running everything in the cloud or everything on premise. They'll be the ones that get comfortable with both at once: using hyperscalers and SaaS for what they do best, while maintaining a firm, auditable, runtime-enforced grip on the credentials, secrets and access decisions. That's not a step backward. It's a more honest architecture for a world where trust can’t be assumed anymore.

These are exactly the questions we build on at Delinea: architecting for on-premise and SaaS, human and non-human, so you’re never locked into one. Our runtime authorization capabilities and our enterprise vault have already built the trust layer this uncertain world is asking for. See what this looks like in your environment.