Identity Is the New Root Access: Rethinking Zero Trust in DevOps Environments

Amal Mammadov is a cloud security and detection engineering specialist working at the frontlines of identity-driven threats in modern cloud environments. His work focuses on how attackers exploit permissions, tokens, and machine identities, often without triggering traditional security controls.

In this conversation, he breaks down why Zero Trust is no longer about networks but about controlling identity in fast-moving DevOps systems.

“Zero Trust” is one of those terms that’s everywhere and somehow still unclear. How do you explain it in a practical way?

Zero Trust has become one of the most widely used and misused terms in cybersecurity, often reduced to marketing language rather than operational reality. To ground the concept, it helps to strip it back to its core principles.

At its core, Zero Trust is about eliminating implicit trust from systems. Access is no longer granted based on where something is coming from, such as being inside a corporate network, but instead on who or what is making the request, under what conditions, and with what level of risk. Every access decision becomes contextual and continuously evaluated rather than static.

This changes the model from a binary notion of “inside equals safe” to a dynamic set of questions: who are you, what are you trying to do, how risky is this action right now, and how long should you be allowed to do it? While the approach may sound restrictive, in practice it often makes systems easier to operate. Access becomes more predictable, more measurable, and significantly easier to audit.

Experts mention that “identity is the perimeter". Why is identity more important than the network now?

As organisations moved to the cloud, the assumptions behind traditional perimeter security quietly broke down. There is no longer a clearly defined “inside” to defend.

In cloud environments, the most critical factor is not whether a system can be reached over the network, but what an identity is allowed to do once it is authenticated. Permissions, not connectivity, define power. Attackers have adapted quickly to this reality. Instead of focusing solely on exploiting software vulnerabilities, they increasingly target credentials, tokens, service accounts, and pipeline secrets.

Once an attacker gains access to a sufficiently privileged identity, they are no longer behaving like an intruder in a traditional sense. They are operating as a legitimate user or service. Often, this means their actions blend seamlessly into normal activity, making detection significantly harder.

The implication is stark: in modern cloud systems, compromise does not necessarily begin with breaking in. It often begins with logging in.

How does DevOps change the Zero Trust conversation?

DevOps introduces a lot more “non-human” activity.

The rise of DevOps has accelerated delivery and innovation, but it has also fundamentally changed how systems behave. Human users are no longer the primary actors in many environments. Instead, pipelines deploy codes, infrastructure is created automatically, and services continuously communicate with each other across platforms.

This shift introduces a new challenge for Zero Trust. It is no longer sufficient to think in terms of employee access. The majority of interactions now involve non-human identities, each with its own permissions, lifecycle, and risk profile.

Securing this environment requires a different focus. Machine identities must be strongly defined and tightly scoped. Credentials need to be short-lived to reduce exposure. Permissions must follow strict least-privilege principles, and production environments must be clearly separated from development and testing. At the same time, every action needs to be observable, with the ability to respond quickly when something deviates from expected behaviour.

Without these controls, the speed and scale of DevOps can amplify risks faster than organisations can manage them.

What are the most common identity-related security failures you see?

Despite increased awareness, many organisations still struggle with the same identity-related weaknesses. These issues are not necessarily complex, but they are deeply embedded in how systems evolve.

As users and services gain access for specific tasks, permissions tend to accumulate without full revocation. Credentials are often long-lived, remaining active far beyond their intended use and creating persistent exposure. Environment boundaries are frequently blurred, allowing development or testing identities to interact with production systems in unintended ways. In many cases, workloads rely on static secrets embedded in code or configuration, which are easily leaked or reused.

A common real-world scenario illustrates how these issues combine. A CI/CD pipeline might be granted broad permissions to simplify deployments. Credentials for that pipeline may be stored in environment variables or configuration files. If those credentials are exposed through logs, misconfigurations, or third-party integrations, an attacker can reuse them without needing to exploit any vulnerability. At that point, the system is not breached through force—it is accessed through design weaknesses.

Most significant incidents are not the result of a single failure but the intersection of several of these conditions.

Let’s talk about solving the “static secret problem" with workload identity. What does it actually solve?

One of the most important developments in modern cloud security is the move away from static secrets toward workload identity. Static credentials, such as API keys or embedded passwords, are inherently fragile. They can be copied, logged, leaked, or forgotten, often without visibility.

Workload identity replaces these static mechanisms with dynamic, short-lived authentication methods. Instead of relying on a permanent key, a service can obtain temporary credentials that are scoped to a specific task and expire automatically. This model reduces the potential impact of credential exposure and limits how far an attacker can move within a system.

Beyond reducing risk, it also improves visibility and control. Access becomes easier to audit, and identities can be defined with much greater precision. In effect, it shifts authentication closer to how physical access works in the real world: more like a temporary badge than a permanent master key.

Developers sometimes push back on Zero Trust because they fear it will slow delivery. How do you handle that?

One of the most persistent concerns around Zero Trust is that it will slow down development. In many cases, this concern is valid, but it is often the result of poor implementation rather than the model itself.

Designing security controls as obstacles creates friction and encourages workarounds. The alternative is to treat Zero Trust as an enablement layer. This means building secure defaults into the system so that the easiest path for developers is also the safest one.

Standardised role templates, self-service access with built-in guardrails, and just-in-time privilege elevation for sensitive tasks can significantly reduce complexity. Short-lived credentials eliminate the need for constant manual approvals while still maintaining strong security boundaries. When implemented well, this approach does not slow teams down. It reduces ambiguity and makes access patterns more consistent, which ultimately accelerates delivery.

What role does automation play in making the process sustainable?

It’s everything.

As systems grow in complexity, manual processes quickly become unsustainable. Attempting to enforce Zero Trust without automation leads to bottlenecks, outdated permissions, and widespread policy bypassing.

Automation changes this dynamic by making identity controls continuous rather than reactive. Permissions can be monitored for drift and adjusted automatically. Unused access can be revoked without manual intervention. Policies can be enforced at deployment time, ensuring that insecure configurations never reach production. At the same time, privileged activity can be continuously analysed, with rapid response mechanisms triggered when risk increases.

At a mature level, identity management begins to resemble infrastructure management. It becomes measurable, repeatable, and consistently enforced, rather than dependent on manual oversight.

Where do you see AI fitting into identity security?

Artificial intelligence is increasingly being applied to security, but its role in identity management is often misunderstood. Its greatest value lies in improving decision-making and accelerating investigation, not replacing foundational controls.

AI can identify patterns that are difficult for humans to detect, such as subtle deviations in service behaviour, unusual access patterns, or sequences of actions that indicate privilege escalation. It can also help organisations refine their permission models by analysing how access is actually used over time.

However, AI does not compensate for weak fundamentals. If an environment is filled with long-lived, overprivileged identities, detection alone cannot prevent compromise. In this sense, AI amplifies the maturity of a system rather than creating it. Strong identity design remains the prerequisite for effective security.

If a company wanted to improve quickly, what would you prioritise first?

For organisations looking to improve quickly, the priority is not perfection but impact. The first step is gaining visibility for all identities, including human users, machine identities, and third-party integrations. From there, reducing long-lived credentials can significantly lower exposure.

Securing CI/CD pipelines and tightening production access should follow, as these are often the most sensitive and least controlled areas. Clear separation between development, testing, and production environments is critical, along with continuous monitoring of privileged actions and predefined response strategies.

Even partial progress in these areas can dramatically reduce risk, as most incidents exploit well-known weaknesses rather than novel techniques.

What’s the biggest misconception about Zero Trust?

Despite its growing adoption, Zero Trust is still frequently treated as a network-centric strategy. This perspective overlooks the reality of how modern systems are compromised.

While network controls remain important, most cloud incidents are fundamentally identity-driven. If identities are not properly issued, scoped, monitored, and revoked, the presence of network defences provides only limited protection. In such cases, Zero Trust becomes more of a label than a functioning security model.

Final thought - what should leaders take away from your approach?

The shift from infrastructure-centric to identity-centric security is not just a technical adjustment; it is a conceptual one. It requires organisations to rethink how access is granted, how risk is evaluated, and how systems are designed.

In a world where machines act as frequently as humans and systems change continuously, identity becomes the most reliable control point. When access is short-lived, tightly scoped, and continuously verified, many of the most damaging types of incidents can be prevented without introducing unnecessary friction.

For leaders, the takeaway is clear. Security is no longer defined by the boundaries you build around systems. It is defined by how precisely you control who and what can act within them.