Cloud security in 2026 (part 2): Why identity is your new firewall

Your data now lives on servers you don’t own, it is accessed by employees working in coffee shops, and it connects to applications running in other clouds. In this environment, the network is no longer your perimeter. Identity is.

If someone has the right credentials, the firewall is irrelevant. Securing who (or what) is logging in is now the most important decision you make.

Below, we look at why managing identity has become so complex, the dangers of having too many digital keys, and why the differences between the major cloud providers can lead to confusion.

Risk of cloud identity sprawl and credential creep

Organizations often leave a trail of digital permissions behind them. We call this cloud identity sprawl.

It happens naturally. Different teams create new servers, make test accounts for developers, and set up automated tools without a central plan. After a while, there are thousands of valid credentials, and you can no longer tell the difference between a legitimate user and a secret backdoor.

Closely related is credential creep. An employee moves from a project in Marketing to one in Finance. They get new access rights, but nobody removes their old ones. Over time, that single account accidentally becomes a superuser with access to almost everything.

The risks here aren’t just theoretical. Attackers love old, neglected accounts that nobody uses anymore. They use them to quietly steal data or use your servers to make money (like mining cryptocurrency). Because the account is supposed to be inactive, nobody notices the activity.

IAM architecture differences

One of the biggest causes of security failures is the assumption that identity is identity across all clouds. It isn’t.

Amazon Web Services and Google Cloud use fundamentally different logic to handle permissions. Applying the mental model of one to the other, you might just introduce security gaps to your system.

The hierarchical structure of Google Cloud

Google Cloud is built like a corporate organization chart. It uses a strict hierarchy: Organization → Folder → Project → Resource.

Google Cloud permissions are additive. If a user has Read access at the Folder level and Write access at the Project level, they have both permissions. You cannot easily subtract a permission lower down.

This is great for global management, but dangerous. If an architect accidentally grants a permission at the Organization level, it instantly trickles down to every single project and database in the company.

The granular policy of AWS

Amazon Web Services is more granular and decentralized. It relies on specific policies attached to users or resources. It relies heavily on Policies (JSON documents) attached to specific Identities (Users/Roles) or Resources (like S3 buckets). Everything is denied by default until you explicitly allow it.

Many AWS services are scoped to a specific region (e.g., us-east-1). Viewing your security posture often requires getting data from multiple regions, whereas Google Cloud gives you a single global view.

Teams often struggle to figure out why a user can’t access a file. This leads to confusion, and engineers often grant too much access just to get things working quickly.

The multi-cloud reality

Most enterprises don’t just stop at two clouds. They are often managing Azure for corporate identity and Oracle for databases. This introduces unique risks that go beyond simple server permissions.

Microsoft Azure

For many, Azure is the source of truth for identity via Microsoft Entra ID (formerly Azure AD). Even if an enterprise primarily runs compute workloads on AWS or GCP, they likely use Entra ID for user authentication.

Entra ID often syncs with your old on-premise Active Directory. This creates a hybrid bridge. If an attacker compromises your on-premise server, they can often move laterally into the cloud.

Azure applies permissions at four levels: Management Group, Subscription, Resource Group, and Resource. A common mistake is applying a role at the Subscription level for convenience, which inadvertently unlocks hundreds of unrelated Resource Groups inside it.

Oracle Cloud

Oracle uses a radically different structure designed for high-security databases.

Unlike AWS’s flat account structure, OCI uses Compartments to logically isolate resources. A network admin can’t even see a database in a secure compartment unless explicitly allowed.

Oracle policies are written in sentences (e.g., Allow group DatabaseAdmins to manage databases). While easier to read, a slight syntax error (like using the verb manage instead of use) can accidentally grant full admin control rather than just access.

Shared fate solution

Expecting your internal team to be perfect experts in the different identity models of AWS, Google Cloud, or Azure is unrealistic. It creates a competence gap.

This is where the shared fate model becomes practical — you can read more about it Cloud security in 2026 (part 1): From shared responsibility to shared fate.

Instead of dealing with the complexity of every platform, you can partner with a managed services expert. At Revolgy, we make sure you get:

• Expertise on demand: We provide access to certified experts who understand these distinct architectural differences.
• Watching for changes 24/7: We don’t just help you set it up; we help you monitor it. We check your infrastructure to find issues — like a permissions error or a dormant account — before it becomes a breach.
  

What’s the technical fix

The ultimate goal for modern cloud identity is simple: zero long-term secrets.

The days of saving API keys on developer laptops or hardcoding passwords into scripts are over. If a static credential exists, it will eventually be stolen.

1. Workload Identity Federation

Instead of giving external applications (like GitHub Actions or on-prem servers) a permanent access key, they should use Workload Identity Federation.

Your application authenticates with a trusted provider to borrow a cloud role for a few minutes. It gets a short-lived token, does the job, and the token expires. There are no keys to rotate and no secrets sitting in your code repository for a hacker to find.

2. Just-In-Time (JIT) access

The rule is that nobody should be an admin 24/7. When a developer needs to fix a production bug, they should request Just-In-Time (JIT) access.

They get the permissions they need for a specific window (maybe a few hours). When time’s up, the access disappears. This limits the damage if someone’s account gets compromised; even if an attacker steals their password later, they log in to find an account with zero privileges.

3. Automated auditing (CIEM)

Finally, you cannot check permissions manually. You need Cloud Infrastructure Entitlement Management (CIEM) tools. These scanners look for over-privileged accounts, like a service bot that has permission to delete databases but hasn’t used it in 90 days, and recommend removing those unused rights.

Key takeaways

Identity is the most critical part of your technical defense, but it is also the most confusing. The clouds are powerful, but their deep architectural differences create real risks for human error.

By using newer approaches like Workload Identity and working with people who understand these different environments, you can protect your systems without overwhelming your team.

Identity mistakes are hard to spot until it is too late. Get a free consultation with our experts to review your architecture and ensure you aren't leaving any digital doors unlocked.