Nov 3, 2025

A new way to think about zero trust for workloads Static credentials have been a weak point in cloud security for years. A new paper by researchers from SentinelOne takes direct aim at that issue with a practical model for authenticating workloads without long-lived secrets. Instead of relying on static keys, the team proposes using temporary, verifiable tokens that expire within minutes. Breaking from static credentials The researcher’s core argument is that static keys are incompatible with zero trust. These credentials often last months or years, and if stolen, they can give attackers broad access to cloud resources. In multi-cloud settings, this becomes even harder to manage. Each static key adds to the operational load of rotating, auditing, and securing thousands of secrets that can be reused across environments. The researchers built and tested their model in a large enterprise environment that spans more than 100 Kubernetes clusters and multiple public clouds. Their system replaces static credentials with short-lived, cryptographically signed tokens that workloads use to prove their identity to other systems. Chris Boehm , Field CTO at Zero Networks, told Help Net Security that the concept aligns with how CISOs should approach zero trust in practice. “If I were advising a CISO, I would tell them to start with visibility. You must know every workload and understand who or what communicates with it. Then reduce access to the minimum necessary and allow privilege elevation only through controlled and monitored actions,” Boehm said. A federated model built on open standards At the heart of their approach is Workload Identity Federation (WIF) and OpenID Connect (OIDC). Together, these technologies allow workloads to authenticate through trusted identity providers rather than storing credentials locally. In practice, this means a workload requests a signed JSON Web Token (JWT) from its environment’s identity provider. The token contains claims such as who issued it, who it represents, and who can accept it. When the workload presents this token to another cloud service, that service checks the signature and verifies that the token was issued by a trusted provider. If the verification passes, the cloud issues a temporary credential for that request. The token is short-lived and scoped to a specific purpose, so even if it were stolen, its value to an attacker would be limited. The researchers describe this as a federated approach, where identity and trust flow between clouds through established, auditable relationships. Each request is verified independently, which supports the zero trust principle of “always verify.” Tested at enterprise scale SentinelOne deployed this architecture in its own production environment, which includes workloads across AWS, Google Cloud, and Azure. Before adopting the federated model, the environment used thousands of long-lived keys for service accounts, user identities, and cloud applications. After the shift, those static keys were replaced with on-demand tokens that last less than an hour. This reduced the average credential lifetime by more than 99 percent and cut the burden of managing secrets across platforms. The team also reported an 80 percent drop in the time needed for compliance audits, since the trust model became centralized and easier to trace. For developers, provisioning secure cross-cloud access went from taking days to minutes. The system automatically enforces least privilege by using claims within each token to limit what the workload can do and for how long. Cutting risk through short-lived access The paper compares the risk models of static credentials and federated tokens. In the legacy model, overall risk grows with the number of keys, their long lifetimes, and the wide permissions they often carry. The new model changes that by reducing lifetime and scope. A token might exist for only 60 minutes and be tied to one workload or API. This lowers the “blast radius” of any single compromise. The authors show that by shifting from persistent credentials to ephemeral tokens, the operational complexity also drops. Instead of managing thousands of secrets, teams manage only a few trusted identity providers. This helps control costs by reducing manual work and limiting resource duplication. Built-in defenses against known threats The framework addresses several common risks. The “Confused Deputy” problem, where a service is tricked into misusing its authority, is prevented by the audience claim in each token, which ensures it can only be used by its intended target. The model also removes the need to store secrets in files or secrets managers, reducing the risk of leaks during credential distribution. For third-party integrations, trust can be created through federation with the vendor’s identity provider and revoked instantly if needed. This avoids the slow and uncertain process of rotating static keys. Continuous verification redefined One of the most important ideas in zero trust is continuous verification, which the SentinelOne framework supports by requiring every workload interaction to be reauthenticated. Boehm noted that this concept is often misunderstood. “Continuous verification should not mean more MFA prompts or stricter NAC rules,” he said. “Those are momentary checks that expire the second access is granted. True continuous verification comes from using behavioral and contextual signals such as process activity, communication patterns, and timing to reassess trust dynamically.” His point echoes the research’s focus on minimizing implicit trust at the workload level. The paper shows that by combining identity federation with short-lived tokens, each request becomes its own trust decision, based on fresh data rather than static credentials. The road toward dynamic authorization While the current work focuses on authentication, the authors see room for expansion. They propose linking this system to attribute-based access control (ABAC), where tokens could include contextual information such as project tags or workload metadata. This would allow access decisions to change dynamically based on attributes. They also mention the idea of “just-in-time” credential issuance, where a token would exist only for the duration of a specific task or job. That would further narrow the window for attackers to exploit stolen credentials . More about