Who Controls Trust? How Do You Regain It?

Portability Is More Than Moving the Workload

In this series, we define Security Sovereignty as retaining control over identity, authorization, and policy even when providers, infrastructure, or operating conditions change. We first asked who controls trust, then what happens when that control is put under pressure and normal stops being normal.

The next question is perhaps the most practical one: if you discover that too much of your ability to authenticate, authorize, and enforce policy depends on a provider you don’t control, how do you get that control back?

The obvious answer is portability. As far as it goes, it is a good answer. The problem is that portability is often understood mainly as technical workload mobility: can the application, its data, and its infrastructure be moved from one environment to another?

An application can run in a container, a database can be replicated, and infrastructure can be described as code and recreated elsewhere. With enough preparation, a workload running in one cloud today can run in another tomorrow.

All of that is useful. But it describes only one layer of portability.

However, it does not guarantee that control has moved with the workload. If the application starts perfectly in its new environment but can no longer establish the same identities, interpret the same authority, apply the same business policies, or reproduce the same trust relationships, then you have technically moved the application while operationally leaving critical parts of it behind.

At that point, it is no longer just a technical migration problem. Customers may be unable to access services, partners may no longer be able to establish trust, business processes may be interrupted, and the organization may discover that it cannot change providers on its own timeline. What looked like a portability issue has become a business continuity issue.

That gap between running somewhere else and actually being in control somewhere else is where Security Sovereignty becomes considerably more difficult.

The hardest things to move

Infrastructure has the advantage of being visible. Servers, clusters, networks, databases, regions, and availability zones all have a place on an architecture diagram. Because they are on the diagram, everyone understands that they need backup strategies, migration paths, and alternatives.

Authority rarely receives the same treatment.

A business may know exactly where an application runs and still be unable to say where the rule lives that lets a customer cancel their own reservation but not someone else's. It may sit in application code. It may be implied by a scope. Part of it may live in a gateway, another part in the identity provider, and a third in the user interface. And, if we are honest, much of it may simply live in the heads of the people who built the system and know how it is supposed to work.

That arrangement can run happily for years, right up until the moment you need to move.

When we discussed the first article, Kin Lane, the API Evangelist,  made an observation I keep coming back to: you cannot be sovereign over trust that was never made explicit.

That gets to the heart of the portability problem. An authority boundary that exists only implicitly gives you nothing to carry with you.

Moving the infrastructure does not preserve it. Changing identity providers does not recreate it. Deploying the same application in a different environment does not guarantee that anyone or anything there will understand or enforce the same rules.

Before trust can become portable, it must first be visible.

Portability runs deeper than deployment

That is why portability needs to be considered in layers rather than treated as a question of where a piece of software can be installed.

The first layer is technical: can the critical security services actually operate in another environment? If an identity or authorization capability exists only as a native service inside one provider's platform, moving it to another environment may not be possible in the first place.

But being able to install the same software somewhere else is only the starting point.

The identity model has to survive the move as well. Every API validating your tokens has been configured to trust a particular issuer and a particular set of signing keys. Every partner in a federation trusts your metadata and certificates. Every client was registered against specific endpoints. Every passkey your customers created is bound to the relying-party ID for which it was created.

You may be able to redeploy an identity server in an afternoon, but if the signing keys cannot leave the provider's key-management service, or the issuer changes along the way, everything that trusted you yesterday has to be persuaded to trust you again.

Moving to another environment also means making sure existing systems and partners can still recognize and trust your identity services. Users, applications, workloads and AI agents must be identifiable in the new environment, without disrupting the trust relationships they depend on.

Then there is authorization. Can the business rules that determine who may do what move with the organization, or have they become inseparable from one provider's proprietary policy model?

Authorization belongs to the business, not the platform.

Its implementation may change from one environment to the next, but its meaning should not. A claims handler might be authorized to approve payments up to a certain amount, while an AI agent can retrieve records but not modify them, and a customer can only change resources they own. Those rules should remain intact when moving to a different environment.

Deployment independence alone does not get you there. Sovereignty also requires policy independence.

One more thing has to travel: the rules for how authority changes when conditions deteriorate. A resilient trust model should define in advance which capabilities continue, which are restricted, and which require human approval as the organization moves from normal operation into degraded or crisis conditions.

Having to move away from a provider unexpectedly is already a difficult situation. If the rules governing how authority should be restricted during a crisis are tied to that provider's platform, you risk losing access to them when you need them most.

Standards help, but do not finish the job

Open standards play an important role in identity and API security. OAuth and OpenID Connect provide  common protocols for authorization and authentication,  allowing systems built by different vendors to work together. Token exchange allows a token to be exchanged for one intended for another security domain, without passing the original credential to every downstream service.

These are important building blocks precisely because they reduce the amount of trust that exists only inside one vendor's implementation.But standards alone do not make an architecture portable. 

This is where zero trust architecture adds an important principle. Access to enterprise resources should be protected at the APIs themselves, using least-privilege access tokens that carry the scopes and claims those APIs need to make the correct authorization decisions. When authority changes, the authorization server can issue tokens that reflect that change, and the APIs can respond accordingly.

That separation matters for portability. The authorization server establishes and communicates authority, while APIs enforce the boundaries around the data and operations they protect. The business rules should not be tied to a particular cloud platform or proprietary gateway configuration.

You can still use OAuth badly, of course. A standards-based token can carry permissions that are far too broad, and an organization can still bury critical authorization logic in infrastructure-specific configuration. The protocol may be portable while the authority model is not.

The harder and more valuable work is therefore making the organization's intent explicit: what authority should be granted, how narrowly it should be bounded, which resources it applies to, and how APIs should respond when that authority changes.

That is what turns open standards from a technical interoperability mechanism into part of a portable trust architecture.

Those decisions do not belong to the infrastructure provider. They belong to the organization. The more clearly they are expressed, the easier it becomes to preserve them when the technology underneath changes.

Regaining control is not leaving the cloud

None of this means every organization should start planning its exit from the public cloud. Reading it that way misses the point entirely.

Security Sovereignty is not a migration program disguised as an architectural principle. It is about making sure migration remains a credible option.

If a provider gives you excellent service, strong resilience, and the capabilities you need, there may be no reason to leave them at all. The sovereignty question is whether staying is still a choice you are making.

The real test is whether you could move if circumstances changed, and whether your business could continue operating during that transition. Could you reproduce the same identity and authorization capabilities, policies and trust relationships in a different environment?

Arelion offers a useful example of one part of this problem. Following its divestment from Telia Company in 2021, it had two years to establish a fully independent IT landscape. That meant more than moving workloads or choosing a new cloud provider. It had to establish an identity foundation it could operate and control as an independent business.

Arelion built that foundation around open standards and established an identity layer it could operate on its own terms. The important point is not where the identity layer runs, but that identity itself was not left inseparably tied to the environment it was leaving.

PagerDuty offers a related example. Its platform runs on AWS, but it operates the Curity Identity Server inside its own network and uses a common identity layer across its European and US regions. The cloud remains part of the architecture, while control over identity remains with PagerDuty rather than being defined entirely by the surrounding cloud platform.

Both examples show how organizations can retain control over their identity infrastructure rather than becoming dependent on a single provider. But identity is only part of the picture. Authorization rules, policies and trust relationships also need to survive a move to a different environment without changing their meaning.

This doesn’t mean that organizations should avoid cloud providers. Dependencies are part of modern enterprise architecture, and most of them cause no concern. The problem begins when a critical dependency has no meaningful substitute, no migration path, and no controlled way to operate without it.

AI turns portability into authority

Agentic AI adds another dimension because an agent may act across several systems in the course of a single task. In that situation, identity alone is not what needs to survive a change of environment.

What has to survive is the meaning of the agent's authority: what it is allowed to do, which resources that authority applies to, and where its boundaries lie.

That is also why broad permissions are such a poor substitute for portability. A generic admin role may be easy to reproduce elsewhere, but all that really means is that excessive authority can travel with you.

The objective should be authority that remains explicit, bounded, and understandable wherever it is enforced.

That shift from identity to authority is the subject of the next article, From Identity to Authority: How Trust Gets Established.

For now, the important point is simpler: an organization cannot move control if it does not know precisely what needs to move.

Portability is preserving meaning

Discussions about vendor lock-in often focus on products and deployment models. But there's more to portability than that.

An organization also needs to preserve the meaning behind its identity and authorization model. Who does an identity represent? What authority has been granted, and for what purpose? What business rules do the policies enforce? Will the same trust relationships and security boundaries still apply? These things need to remain consistent even when the underlying infrastructure changes.

If those meanings survive the move, the technology underneath them can change without forcing the organization to reinvent its security model. That is a far stronger form of portability than being able to start the same container in a different region.

Infrastructure can change. The trust model should not have to change with it.

That also sharpens the test for Security Sovereignty. Can identity and authorization keep operating when infrastructure, providers, or jurisdictions change? I would extend that question further.

Do not stop at asking whether the application can run somewhere else. Ask whether identities can still be established, authority can still be understood, business policies can still be enforced, and trust relationships can be rebuilt without relying on the provider you are trying to leave.

If they can, changing infrastructure is an engineering challenge. If they cannot, it is a sovereignty problem.