The MCP Authorization Specification relies on OAuth for the scopes that define the set of actions an authorized client is allowed to take on behalf of the user. Scopes are a useful part of securing MCP servers. They define broad capability sets a client is allowed to exercise. But if you rely on scopes alone to enforce authorization for MCP tools, you will run into real limitations when building secure, multi-user, role-aware systems that require fine-grained access controls.
OAuth scopes were designed to signal high-level API privileges, like “read contacts” or “write calendar”. They work well for delegated access where a client needs permission to call an API on a user’s behalf. The challenge is that MCP authorization is a more nuanced control problem than delegation can solve on its own:
Scopes control what area of functionality you can touch
MCP authorization must control who can run which tool under what conditions
Scopes don’t provide the structure needed to map least-privileged user roles to permitted actions in a dynamic tool ecosystem. This matches general OAuth guidance that scopes are for broad API permission surfaces, not fine-grained role models.
Tokens are static, MCP policies must be dynamic
OAuth tokens are static snapshots of what the client was allowed to do at the time they were issued. Once a token is minted, those permissions don’t change until it expires.
But user roles and organizational policies are constantly evolving. Users get promoted, responsibilities shift, standards are introduced and tool access needs to adapt immediately. Embedding all permissions into a token means:
You either issue a multitude of tokens for every variation of policy combinations
Or you accept the risk of tokens that are too permissive and too persistent
Neither is ideal. True RBAC systems let the server evaluate user role and permissions at runtime, instead of inherently trusting a pre-issued token.
Scopes quickly take on a life of their own
If you try to model every MCP tool with a distinct OAuth scope, you quickly hit practical limits:
OAuth scopes become big and unwieldy
Tokens grow large because JWT headers must stay within HTTP size limits
Every new tool or operation requires a new scope definition.
This leads to scope sprawl that is hard to manage and consumes token space inefficiently. It’s a common anti-pattern in APIs that start with scopes and then try to extend them to fine-grained permissions.
Scopes lack contextual awareness
Scopes say what, but not when, why, or on whose behalf.
Consider a scenario where:
Alice can use the billing:update tool for her own projects.
Bob can use the same tool across all projects.
Both might have a scope like mcp.billing.update. Scopes alone cannot distinguish context such as:
Which project the user is targeting.
Whether the action is allowed for this user on this resource.
True RBAC systems embed this logic either server-side or via richer policy languages. Scopes cannot express it without becoming deeply unwieldy.
Scopes don’t capture intent or sequencing
An MCP server must consider the semantics of multi-step operations. A single scoped call might be valid, but a sequence of calls could exceed what the user should actually be allowed to do (e.g., a low-privilege user chaining several tool calls to achieve a high-impact effect). That kind of sequence-aware authorization is outside the scope (pun intended) of simple OAuth scopes.
Roles are essential
In RBAC, the unit of authorization is the role: a named bundle of permissions aligned with organizational responsibilities. Scopes are not roles, they are just flags on a token. In contrast, RBAC systems typically support:
Role hierarchies (admin > editor > viewer)
Permission grouping
Dynamic reassignment
Scopes do none of this. At best, scopes can mirror roles, but only if you duplicate role logic into scope names which quickly becomes messy and brittle.
Scopes + server-side RBAC: The right balance
OAuth scopes are useful for coarse access boundaries because they help a resource server quickly determine if a client has broad permission to a domain (e.g., “this client is allowed to talk to MCP billing tools”).
But fine-grained, role-aware MCP authorization belongs on the server, where user identity, role context and organizational policy can be enforced at the time of the request.
This hybrid approach combines:
Scopes for binding tokens to broad capabilities
RBAC/permissions enforced in the MCP server at the tool level
It gets you strong security, manageable tokens and flexible policy enforcement.
Conclusion
OAuth scopes solve an important part of the authorization puzzle: delegated capability. But they are only one piece. MCP access control that relies on scopes alone will struggle with:
Dynamic user roles
Per-tool permissions
Contextual resource access
Runtime policy evaluation
To do MCP authorization properly, you need scopes for the big picture and server-side RBAC for least-privilege enforcement.
Securing Identity in the Age of AI: A Buyer’s Guide to Teleport – Teleport
As enterprises embrace AI, identity has become the defining security challenge. Every new database, Kubernetes cluster, SaaS app, and now every AI agent introduces yet another identity that must be governed and protected. At the same time, attackers are weaponizing AI to accelerate identity-based threats, exploiting fragmentation and credential sprawl to devastating effect.
For buyers evaluating how to secure modern infrastructure in this new landscape, the question is not whether identity is central to security — that debate is over. The question is how to unify and govern identity across both humans and AI systems without slowing down the pace of innovation.
This guide is designed for security leaders, engineering teams, and decision-makers exploring how Teleport addresses this challenge. You’ll find:
A breakdown of the problem and why AI compounds existing risks
Teleport’s approach to modern identity security
How Teleport secures new frontiers like MCP and AI agents
The risks you must consider as a buyer
Evaluation criteria and a phased adoption roadmap
💡 The Takeaway
By the end of this guide, you’ll understand why Teleport is not just another access tool, but a unified identity platform built for the realities of AI-powered infrastructure.
Executive Overview
The AI Identity Challenge
Modern infrastructure has outpaced traditional identity security models. Scale, complexity, and fragmentation of identity are now the root causes of today’s security challenges. Every new silo of identity — databases, Kubernetes, SaaS apps, or AI agents — expands the attack surface. IT teams can’t keep up, so responsibility falls to engineering and infrastructure groups already under pressure to move faster.
AI only accelerates these challenges. On one hand, it lowers the cost of executing identity-based attacks. On the other hand, the rise of LLMs and agentic AI — autonomous systems that plan, act, and interact across tools — introduces a flood of unpredictable events and new classes of identities that legacy security tools cannot govern.
Teleport’s Answer: Cryptographic Identity
Teleport redefines identity for modern infrastructure. The Teleport Infrastructure Identity Platform implements trusted computing at scale, delivering unified cryptographic identities for humans, machines, workloads, endpoints, infrastructure assets, and AI agents.
Unlike fragmented point solutions, Teleport vertically integrates:
With Teleport, anonymous actors disappear. Every access request is tied to a cryptographic identity bound to a fingerprint, device, and short-lived certificate. Access is scoped to a single unit of work and expires as soon as that task is complete. Teleport calls this steady-state computing: when nothing is happening, no one has access.
The Final Outcome
The result is a consistent security foundation that scales with modern infrastructure and AI. Humans and agents alike are provisioned, governed, and audited under one model. Standing privileges vanish, policies remain consistent, and every action is attributable and accountable.
With this foundation in place, organizations can turn to two of the fastest-growing frontiers in enterprise security — MCP and AI agents.
Understanding MCP and AI Agents
As organizations embrace AI, new protocols and workflows emerge that require first-class governance. Teleport extends its identity-first approach into this evolving landscape.
MCP
The Model Context Protocol (MCP) is an open standard that connects large language models to enterprise resources and applications. In Teleport, MCP is treated no differently than SSH, Kubernetes, or databases — a protocol governed by the same identity-based, policy-driven controls.
By applying Secure MCP, organizations gain consistent access control and identity governance across humans and workloads. Every MCP privilege is:
Short-lived
Scoped to the task
Fully auditable
Agentic AI
Agentic AI describes autonomous systems capable of chaining actions across APIs, databases, and internal tools. Today, many of these agents operate outside proper governance, often using static credentials or ad hoc integrations.
Teleport changes that model by treating agents as first-class identities. Each receives:
Cryptographic certificates
Task-scoped privileges
Automatic expiration
This ensures AI agents cannot accumulate excessive privileges or persist beyond their intended unit of work.
Humans in the loop
Teleport preserves human oversight. By linking prompts to agent actions, every step an AI system takes is tied back to a human origin, creating a transparent audit trail that maintains accountability and policy alignment.
With MCP and agentic AI secured under one model, the next challenge is addressing the risks they bring.
Risks & Challenges
Every organization faces a dual set of risks: long-standing security weaknesses in infrastructure, and new AI-specific threats that compound them. Teleport addresses both.
General risks
1. Over-privileged access Agents or users requesting broad access can wreak havoc. Teleport enforces least privilege through just-in-time, task-scoped access.
2. Credential sprawl Passwords, SSH keys, and tokens remain the #1 attack vector. Teleport replaces them with short-lived cryptographic certificates.
3. Audit blindness Fragmented logs obscure accountability. Teleport provides end-to-end monitoring and real-time alerts across the identity chain.
4. Human error Misconfigurations, phishing, and mistakes remain common. Teleport removes the conditions that make errors exploitable by design.
Agentic AI Identity provisions ephemeral, task-scoped certificates and just-in-time requests contextualized to intent.
Teleport extends these protections further with MCP Catalog, a curated list of approved AI tools wrapped in identity governance and policy enforcement.
💡 The Takeaway
Together, these guardrails prevent AI from becoming an unmanaged silo, giving buyers the confidence that AI adoption won’t expand risk exposure.
Securing the Full Surface Area
Modern infrastructure demands security that spans every layer of interaction. Teleport’s principle is simple but powerful:
Treat every prompt, API call, and agent action as an identity event.
Here’s what this principle looks like in practice.
2. Agents & backend Ephemeral, cryptographic IDs scoped by RBAC/ABAC provide traceability. Session recording and interactive controls offer full auditability.
3. Unified identity everywhere From SSH to databases to APIs, Teleport enforces zero-trust, policy-driven access while eliminating shared secrets.
This unified approach makes identity the connective tissue for security across both classic infrastructure and AI-driven systems.
Buying Criteria
Choosing a security platform today requires forward-looking criteria that address both legacy infrastructure and the realities of AI.
Teleport delivers on the following:
✔ Unified cryptographic identity for humans, workloads, and AI agents. ✔ Just-in-time, task-scoped ephemeral certificates. ✔ One governance language spanning Zero Trust Access and Identity Governance. ✔ End-to-end, audit-grade accountability. ✔ Identity-based zero trust enforcement across all protocols. ✔ Shadow access detection and remediation. ✔ Cloud-agnostic integration across AWS, Azure, GCP, and on-prem.
These are not “nice-to-haves.” They are the baseline requirements for securing the future of identity.
Implementation Path
Modernizing identity doesn’t have to be overwhelming. Teleport recommends a phased approach:
1. Start in steady state No one has access unless a change is occurring. All access is issued as short-lived certificates tied to specific work.
2. Deploy in phases Replace VPNs and secrets with Zero Trust Access, then layer on Identity Governance, and finally expand into Identity Security.
3. Add AI incrementally Treat MCP as just another protocol. Secure MCP, Agentic AI Identity, and MCP Catalog are natural first steps for AI infrastructure.
This path allows organizations to quickly eliminate risk while building toward long-term resilience.
Why Teleport for AI Security
Teleport is not just another access tool. It’s a new approach to identity security, adapted for modern infrastructure and AI.
Eliminate secrets and standing privilege.
Unify access and governance across humans, workloads, and AI.
Expose and remediate hidden identity risks.
Adopt steady-state computing: no access unless work is happening.
Treat agents as first-class identities, not unmanaged silos.
By securing every identity — human or machine, static or dynamic, classic or AI — Teleport delivers the foundation organizations need to innovate confidently in the era of AI.
Learn more about Teleport for securing AI infrastructure and identity, or reach out to see how it works in person.
Non-Human Identities (NHIs) vs. Machine Identities: Key Differences & Security Best Practices – P0 Security
What Are Non-Human Identities (NHIs) & Why Do They Matter?
Identity extends far beyond human users. Non-Human Identities (NHIs) have become an essential component of modern IT ecosystems, facilitating communication between devices, applications, and services. However, there is growing confusion in the market about what NHIs truly encompass, particularly when differentiating them from machine identities. Understanding these distinctions is crucial for organizations aiming to secure their environments effectively.
Defining Non-Human Identities (NHIs)
Non-Human Identities (NHIs) refer to digital identities that are not associated with individual human users. These identities can belong to:
Devices – IoT sensors, network routers, laptops, and mobile devices
Set up real-time monitoring for unusual NHI behavior, such as unexpected credential usage.
Use Identity Threat Detection and Response (ITDR) solutions to detect and mitigate identity-based threats.
FAQ: Addressing Common NHI Security Questions
Q: What’s the biggest risk with Non-Human Identities?
A: Unmanaged NHIs, like stale service accounts or exposed API keys, can be exploited by attackers for lateral movement.
Q: How should organizations prioritize NHI security?
A: Start with discovery, enforce least privilege, and implement automated monitoring to detect unauthorized NHI usage.
Q: How is a machine identity different from an NHI?
A: All machine identities are NHIs, but not all NHIs are machines. Machine identities specifically apply to workloads, devices, and cloud services, whereas NHIs also include software bots, legal entities, and RFID-tagged animals.
Conclusion
Non-Human Identities (NHIs) are essential to digital ecosystems, but organizations must clearly differentiate between machine identities and other NHIs to implement effective security controls. While machine IAM focuses on securing workloads and devices, broader NHI governance includes service accounts, API keys, and even legal entities.
By following best practices in discovery, management, access control, and monitoring, organizations can reduce security risks and ensure NHIs remain an asset rather than a liability. The key is to implement identity-first security strategies that account for the growing complexity of non-human entities in cloud-driven environments.
Beyond Secrets: How Managed Identities Are Transforming Multicloud Security – GitGuardian
Managed identities offer a paradigm shift from “what fo you have”to “who you are” authentication, providing automated, short-lived credentials that eliminate credential sprawl across multicloud environments.
As organizations embrace cloud-native architectures and microservices, the number of machine identities such as applications, containers, CI/CD pipelines, and IoT devices has exploded. Security experts call this a “machine-first world” where non-human actors vastly outnumber human users.
This transformation has exposed the fundamental weakness of traditional secret management. For decades, organizations have relied on static secrets like API keys, passwords, and tokens that function as unique identifiers for workloads. While this approach provides clear traceability, it creates an operational nightmare of manual lifecycle management, rotation schedules, and the constant risk of credential leakage.
What Are Managed Identities
Rather than embedding static credentials into applications, modern platforms now provide identity services that issue short-lived, automatically rotated credentials to authenticated workloads. This includes cloud providers, CI/CD systems, and other infrastructure platforms.
How Major Platforms Are Eliminating Static Credentials
Each major cloud provider has developed sophisticated managed identity systems, though their approaches differ significantly. AWS pioneered the concept with IAM Roles for EC2 instances, where the metadata service automatically provides temporary credentials without requiring any static keys. This pattern has expanded to Lambda functions, EKS clusters through IAM Roles for Service Accounts (IRSA), and virtually every AWS service.
Azure took this concept further with Managed Identities that extend across their entire service portfolio. A Function App can seamlessly authenticate to Key Vault, Storage, and other Azure services using its managed identity, eliminating the need for connection strings entirely. Google Cloud’s approach centers on Service Accounts enhanced with Workload Identity Federation, enabling sophisticated scenarios where workloads running outside Google Cloud can authenticate using their existing identities.
The revolution extends beyond cloud providers to CI/CD platforms. GitHub Actions now supports OpenID Connect (OIDC) tokens that allow workflows to authenticate directly to cloud providers and other services without storing long-lived secrets. Similarly, GitLab’s OIDC provider enables CI/CD pipelines to obtain temporary credentials for cloud deployments, eliminating the need to store AWS access keys or Azure service principal secrets in pipeline variables.
The evolution is perhaps most visible in Kubernetes, where service accounts have transformed from simple static token holders to sophisticated identity bridges that can map to cloud IAM roles without ever exposing static credentials.
The Cross-Cloud Authentication Challenge: Why Static Secrets Don’t Scale
The complexity of this transformation becomes apparent when organizations operate across multiple clouds. Consider the perspective of a DevOps engineer managing a multicloud environment: “Having a workload in Azure that needs to read data from AWS S3 is not ideal from a security perspective. Cross-cloud authentication and authorization complexity makes it hard to set this up securely, especially if we choose to simply configure the Azure workload with AWS access keys to access S3.”
This real-world challenge has traditionally driven organizations toward centralized secret management solutions like CyberArk Secrets Manager or HashiCorp Vault, which provide a universal broker for secrets across platforms. While this approach offers centralized management and native synchronization capabilities, it perpetuates the fundamental problem: the proliferation of static secrets that require careful management and rotation.
Managed identities fundamentally change this equation by eliminating many of the secrets that require synchronization in the first place. Instead of managing database passwords, service API keys, and connection strings across multiple clouds, organizations can leverage native identity systems that handle authentication dynamically.
What Managed Identities Replace: From Database Passwords to API Keys
The transformation becomes clear when comparing traditional and managed identity approaches:
However, the reality is more nuanced. While managed identities eliminate many secrets, they don’t solve every authentication challenge. Third-party APIs still require API keys, legacy systems often can’t integrate with modern identity providers, and cross-organizational authentication may still require shared secrets.
The authors of “Solving the Bottom Turtle — a SPIFFE Way to Establish Trust in Your Infrastructure via Universal Identity” say: “using a secret manager dramatically improves the security posture of systems that rely on shared secrets, but heavy use perpetuates the use of shared secrets rather than using strong identities”. The goal isn’t to eliminate secret managers entirely, but to dramatically reduce their scope.
Architecture Patterns for the Real World
Modern multicloud architectures increasingly adopt a hybrid approach that strategically combines managed identities with traditional secret management:
This architectural pattern reflects the practical reality. Some workloads can fully embrace managed identities. Others need hybrid approaches that bridge different identity systems. And some still require traditional secret management for legacy systems that can’t be modernized.
The Economics of Identity
The business case for managed identities extends beyond security improvements. Organizations implementing these systems report dramatic productivity gains. Enterprise case studies document a 95% reduction in time spent managing credentials per application component, and a 75% reduction in time spent learning platform-specific authentication mechanisms, resulting in hundreds of saved hours annually.
The security benefits are equally compelling. By shifting from static credentials to cryptographic identities, organizations enable automatic rotation, reduce their attack surface, and create better audit trails. As one healthcare organization implementing managed identities noted, “We wanted to shift away from secret management practices in general. Instead of asking a service, ‘what do you have,’ we want to ask, ‘who are you'”.
When to Use Cloud-Native vs. Universal Identity Solutions
The decision framework for managed identities depends heavily on your architectural context:
The migration path typically follows a predictable pattern: start with cloud-native workloads using platform-native managed identities, expand to cross-cloud scenarios through federation, and gradually reduce reliance on static secrets through automation and integration.
It’s important to understand how managed identities compare to other identity approaches. The choice isn’t always binary – sometimes you need a combination of strategies:
This comparison reveals why many organizations end up with hybrid approaches. Pure managed identities excel for cloud-native scenarios but struggle with legacy systems and true multi-cloud portability. Universal identity solutions provide flexibility but add operational complexity compared to simple, single-cloud managed identities.
Emerging Standards: Building Interoperable Identity Across All Platforms
The industry is converging on standards that will make managed identities even more powerful and interoperable. Emerging frameworks aim to create “acommon language for workload identities across clouds and platforms,” enabling standard translation between identity formats and eliminating the custom integration work that currently complicates multicloud authentication.
This standards-driven future promises to resolve the tension between vendor-specific managed identities and the need for universal, portable workload identity. Organizations that begin their managed identity journey today are positioning themselves to take advantage of these emerging standards as they mature.
The transformation from secret management to identity management represents more than a technical upgrade—it’s a fundamental shift toward more secure, scalable, and maintainable authentication architectures. In a world where machine identities outnumber human users by orders of magnitude, managed identities provide the foundation for the automated, auditable, and secure systems that modern organizations require.
Mastering Machine Identity Management: The Key to Securing Non-Human Identities (NHIs) – Akeyless
Posted by Miryam Brand
Introduction: The Silent Threat of Non-Human Identities
Today’s enterprise environments are no longer composed only of human users. Applications, services, containers, and IoT devices, collectively known as non-human identities (NHIs), far outnumber human counterparts. These machine identities require authentication and authorization to interact with systems and data, just like users do. However, while organizations often invest heavily in securing human identities through SSO, MFA, and IAM policies, machine identities are typically underprotected, creating a significant and growing vulnerability.
Failure to manage NHIs effectively exposes organizations to breaches, operational disruptions, and regulatory violations. This gap is where Machine Identity Management (MIM) steps in.
Machine Identity Management Explained
Machine Identity Management (MIM) refers to the processes, tools, and policies used to manage and secure the identities of non-human entities such as applications, services, devices, and containers. These identities are authenticated via secrets—API keys, certificates, credentials—that must be properly issued, rotated, and revoked to minimize risk.
The primary types of NHIs include:
APIs: Secured through API keys, tokens, and certificates.
Service Accounts: Non-human users with often excessive privileges.
Virtual Machines and Containerized Services: Foundational elements of modern cloud-native and DevOps environments.
Databases: Critical repositories of enterprise data requiring secure authentication methods.
Physical Devices and IOT: Requiring secure certificate-based communication.
Each NHI typically uses secrets to authenticate, making secrets management a core component of machine identity security.
Why Machine Identity Management Is Critical
Securing non-human identities is no longer optional in today’s digital landscape. As machine identities continue to proliferate at an unprecedented pace, organizations must recognize the essential role Machine Identity Management (MIM) plays in protecting their environments.
1. Expanded Attack Surface
Each unmanaged or outdated NHI credential represents a potential vulnerability attackers can exploit. As enterprises increasingly adopt cloud-native technologies with vast numbers of interconnected workloads, the attack surface multiplies rapidly, making effective management of machine identities paramount.
2. Enabling Zero Trust and Least Privilege
The Zero Trust security paradigm—embodied by the principle “never trust, always verify”—demands rigorous authentication and restricted access for all entities, including NHIs. Enforcing least privilege ensures machine identities only have minimal permissions required to perform their tasks, significantly mitigating risks.
3. Compliance and Auditability
Regulatory frameworks such as GDPR, HIPAA, and DORA mandate auditable, traceable access controls that extend explicitly to NHIs. Robust MIM practices enable organizations to meet these requirements effectively, demonstrating comprehensive oversight of non-human access to sensitive resources.
How Machine Identity Management Works: Key Practices
Inventory and Discovery: Visibility First
You cannot protect what you don’t know exists. Building a comprehensive inventory of NHIs and their associated secrets is the foundational step in effective machine identity management. Organizations must deploy automated discovery tools to continuously scan infrastructure, pipelines, and applications. These tools help identify hidden machine identities, often automatically generated in dynamic cloud environments, and uncover shadow credentials—such as API keys or tokens embedded directly in source code or configuration files.
A centralized inventory system is essential to maintain visibility. It should document each NHI’s ownership, purpose, location, and credential status, regularly audited to address unmanaged or orphaned identities. This proactive approach prevents hidden vulnerabilities from becoming entry points for attackers.
Lifecycle Management: From Issuance to Revocation
Machine identities, like human identities, must be carefully managed through every phase of their lifecycle. Neglecting any stage, especially early ones like issuance, can lead to severe security vulnerabilities.
Key lifecycle stages:
1. Issuance: Establishing Trusted Identities
Issuance refers to the secure generation and validation of a machine identity at the moment of creation, often involving a cryptographic binding between a public key and the entity’s metadata (such as its service name or role).
For certificates, this step is critical:
A Certificate Authority (CA) must validate the NHI’s legitimacy.
A digital certificate must be securely generated and signed.
Trust chains must be established to ensure the machine identity can be verified across environments.
Example:A Kubernetes workload issues a certificate signing request (CSR) at deployment time. The CA validates the request, signs the certificate, and delivers it securely back to the workload.
Why Issuance Matters: If an identity is issued without strong validation, attackers can impersonate legitimate services. Poorly controlled issuance undermines all downstream security efforts.
2. Provisioning: Credential Distribution and Initialization
After issuance, credentials, whether certificates, API keys, tokens, or SSH credentials, must be securely distributed to the intended workload or device.
Credentials must be injected securely (e.g., via dynamic secret injection).
Secrets should never be hardcoded into application code or static configuration files.
Least-privilege policies should be applied immediately.
Example:A newly provisioned database container automatically retrieves an API key from a secure vault during its startup process.
Key Pitfall to Avoid: Provisioning credentials manually or insecurely often leads to secret exposure, especially through misconfigured pipelines.
3. Rotation: Minimizing Credential Lifetime
Once credentials are in use, they must be rotated regularly to minimize the risk window in case they are compromised.
Secrets like tokens, API keys, and certificates should have built-in expiration times (time-to-live or TTL).
Rotation workflows should be automated to avoid human error or missed updates.
DevOps teams should design pipelines to handle rotated secrets without service interruptions.
Example:A production web server automatically renews its TLS certificate 30 days before expiration without requiring manual intervention.
Key Pitfall to Avoid: Relying on long-lived credentials increases exposure time if they are leaked.
4. Revocation: Immediate Shutdown of Compromised Identities
When an identity is no longer needed, or if a credential shows signs of compromise, it must be revoked immediately.
For certificates, revocation lists (CRLs) or Online Certificate Status Protocol (OCSP) services should be updated.
API keys, tokens, and service accounts must be disabled and decommissioned.
Monitoring systems should alert when revoked credentials are still used (indicating possible attacks).
Example:A service account detected exhibiting anomalous behavior is immediately disabled and its credentials revoked through an automated security orchestration playbook.
Key Pitfall to Avoid: Leaving old or unused credentials active creates major opportunities for attackers to hijack abandoned access.
Why Full Lifecycle Management Matters
Each stage—Issuance, Provisioning, Rotation, and Revocation—builds on the previous one. A weak issuance process cannot be fixed by good rotation practices. Similarly, revoking credentials only matters if you had clear ownership tracking from the moment of provisioning.
Bottom line: MIM without a disciplined, complete lifecycle model is like locking your front door but leaving the windows wide open.
Secure Access and Least Privilege Enforcement: Reducing Risk
Strong access controls are crucial for minimizing the risks tied to machine identities. To be effective, identity-based access policies must clearly define the specific permissions assigned to each machine identity, ensuring they can only interact with the resources necessary for their role. Precision is key: even minor over-permissioning can create serious vulnerabilities.
Role-Based Access Control (RBAC) offers a practical way to organize and streamline permission management. By categorizing machine identities based on their functions, organizations can efficiently assign appropriate access rights, reducing administrative complexity and human error.
Additionally, adopting Zero Standing Privileges (ZSP) strengthens security by removing persistent access rights. Instead of maintaining continuous permissions, machine identities receive temporary, just-in-time access when required, closing off potential avenues for abuse. Regular audits and dynamic adjustments of permissions are essential to ensure that machine identities maintain only the access they truly need, blocking lateral movement and escalation opportunities.
Combining clearly scoped access policies, RBAC grouping, and ZSP practices creates a layered, resilient defense against unauthorized activities, aligning perfectly with Zero Trust principles.
Automation and Monitoring: Scaling Without Losing Control
Managing machine identities at scale demands a strategy built on automation and proactive monitoring. Manual processes simply cannot keep pace with the sheer volume and velocity of identities created in modern cloud-native environments.
Automation ensures that critical steps in the credential lifecycle, from issuance to provisioning, rotation, and revocation, are handled swiftly and consistently. Automating these processes not only reduces human error but also enforces security policies uniformly across highly dynamic systems. In addition, dynamic secret injection at runtime eliminates the risk of credentials being hardcoded into applications or exposed during deployment.
Equally important is continuous monitoring. By leveraging advanced analytics and behavioral baselines, organizations can quickly detect anomalies or suspicious activities linked to machine identities. This real-time visibility enables faster threat detection and response. Automated incident response workflows, triggered by specific monitoring alerts, allow security teams to act immediately, minimizing potential damage and maintaining a resilient security posture.
Integration with Existing Security Infrastructure: No Identity Left Behind
Machine Identity Management (MIM) cannot operate in isolation. For security to be truly effective, MIM must seamlessly integrate into an organization’s broader security ecosystem. This integration ensures that machine identities are managed with the same rigor as human ones and that security gaps do not emerge between systems.
Embedding secret management directly into CI/CD pipelines is critical. Doing so ensures that credentials are securely handled throughout the software development lifecycle without relying on manual processes that introduce risk. Similarly, integrating with Certificate Authorities (CAs) automates the issuance, renewal, and revocation of certificates, maintaining continuous trust across dynamic environments.
Connecting MIM to Security Information and Event Management (SIEM) systems enhances visibility and enables real-time threat detection. Centralized logging and analysis allow security teams to quickly spot anomalies related to machine identity usage. Additionally, using advanced vulnerability scanners to identify misconfigured or exposed secrets across infrastructure proactively closes potential security gaps before they can be exploited.
By weaving MIM into existing security infrastructure, organizations can create a unified, resilient defense: one where no identity is overlooked, and every machine identity is accounted for and protected.
Looking Ahead: Secretless Authentication and Securing Agentic AI
As enterprise environments evolve, Machine Identity Management (MIM) must stay ahead of new challenges. One major trend is the shift toward secretless authentication—a model that eliminates the reliance on static secrets such as passwords, tokens, or embedded keys. Instead, secretless authentication uses identity-based trust frameworks, dynamic validation, and real-time attestation. By validating identities without transmitting or storing long-lived credentials, organizations dramatically reduce their attack surface. This approach pairs perfectly with ephemeral architectures like microservices, containers, and serverless workloads, where identities must be established and verified in milliseconds. The adoption of secretless methods will enhance scalability, simplify operations, and deliver a much higher standard of security in increasingly complex, distributed environments.
At the same time, the rise of autonomous, agentic AI systems presents new and unique security challenges. These AI-driven entities are capable of making decisions, interacting with other systems, and even spawning new processes without human intervention. Traditional static access policies are insufficient for securing such dynamic behaviors. To protect agentic AI, organizations must implement adaptive security frameworks based on continuous behavior monitoring, dynamic risk scoring, and context-aware access decisions. Strong cryptographic proofs of identity, real-time anomaly detection, and policy engines capable of evaluating AI-generated actions on the fly will be critical. As agentic AI becomes more central to business operations, securing these identities will be essential to maintaining trust, preventing rogue behavior, and safeguarding enterprise environments from an entirely new class of sophisticated threats.
Why Akeyless is the Right Partner for Machine Identity Management
As the complexity of securing machine identities continues to grow, organizations need a trusted partner capable of delivering comprehensive, scalable solutions. Akeyless is uniquely positioned to meet these evolving demands with a platform that addresses every critical aspect of Machine Identity Management (MIM).
Our Unified Secrets and Non-Human Identity Management Platform provides end-to-end coverage, including the issuance, rotation, and revocation of credentials, keys and certificates, across dynamic, hybrid, and multi-cloud environments. With built-in automation and Just-in-Time credential creation and revocation capabilities, Akeyless eliminates manual credential management processes, reducing human error and enabling seamless scaling as your environment grows.
Akeyless also empowers organizations to integrate secretless authentication practices, aligning with future-forward security architectures designed for ephemeral workloads and serverless operations. Our platform supports continuous monitoring and real-time visibility into credential usage, providing proactive detection of anomalies and rapid incident response.
Powered by our proprietary Distributed Fragments Cryptography™ (DFC) technology, Akeyless ensures that even we cannot access your secrets, delivering unparalleled privacy, security, and regulatory compliance. Additionally, by embedding secret management into CI/CD pipelines, automating certificate lifecycle processes, and integrating tightly with SIEM and vulnerability management tools, Akeyless fits naturally into your existing security ecosystem without creating silos.
From securing modern DevOps workflows to protecting emerging agentic AI identities, Akeyless helps enterprises future-proof their security strategies while reducing operational complexity and total cost of ownership. Discover how Akeyless can help you master machine identity management and build a resilient, future-ready digital enterprise.
Zero Trust 2025: A 30-day identity-first MVP you can launch – Unosecur
In 2025, Zero Trust has moved from a forward-looking aspiration to the default enterprise security model.
According to recent analysis, most new remote access deployments are shifting from VPN to Zero Trust Network Access (ZTNA), emphasizing identity verification, least privilege, and real-time access governance. However, implementing Zero Trust Architecture comes with its set of challenges. A study published in the International Journal of Engineering Research & Technology (IJERT) shows that tech teams struggle with integrating Zero Trust principles with outdated infrastructures, while managers fail to understand the return on investment (ROI) of Zero Trust implementations, particularly for SMEs.
Zero Trust 2025: Get the fundamentals right
Zero Trust is an architectural and operational shift: continuous verification per session, policy decision/enforcement points, segmentation and isolation, analytics, and automation/orchestration across identity, device, network, app/workload, and data pillars. Often, it’s about getting the fundamentals right.
NIST’s ZTA blueprint and CISA’s maturity model both start with those fundamentals—strong identity, device posture, per-request authorization, and pervasive telemetry—because you can’t do Zero Trust without them. Based on Unosecur’s experience in assessing the identity and access models of organizations across the world, Unosecur has prepared a minimum viable, identity-first Zero Trust plan you can start in 30 days and scale across the enterprise in 90-120 days. It prioritizes access discovery, MFA + passwordless with risk-based controls, least privilege via JIT, machine identity hygiene, and ITDR detections—all with realistic guardrails (fallbacks, exception handling, and phased rollouts).
You also get a starter KPI dashboard so progress is visible to security, IT, and leadership from week one.
Lead with identities and entitlements before networks—this is Zero Trust Identity Security grounded in Zero Trust Architecture. Replace blanket prompts with risk-based authentication and adaptive/activity-based access control.
Prefer passwordless authentication for sensitive actions, but keep SSO and modern fallbacks to avoid lockouts. Shrink standing privilege toward least privilege with JIT. Prioritize entitlement right-sizing via CIEM and governance via IGA/PAM. Use identity orchestration (and where safe, no-code policy orchestration) to change policies quickly without breaking access.
Week 1: Discover and baseline (Days 1–7)
Goal: Know who exists, what they can reach, and where privilege concentrates.
Run access discovery across IDP/AD/Entra, cloud accounts, and top SaaS to map users, groups, roles, non-human identities (NHIs), and effective permissions. Tag privileged identities, externals/contractors, and break-glass accounts; reconcile duplicates; and assign owners for critical apps.
Baseline authentication: MFA coverage (overall/admins), passwordless share, legacy/basic auth usage, and prompts per user. In hybrid identity environments, identify where policy is enforced (IdP vs app vs device).
Reality check: Aim for more than 95% identity inventory coverage, but accept that some fringe systems surface in Weeks 2–3. Capture a “top 10 risks” list (excess privilege, orphaned accounts, legacy hot spots) and publish it on your program dashboard.
Week 2: Authentication uplift (Days 8–14)
Goal: Cut friction without losing security.
Move toward 100% MFA for admins with a managed exception-handling process. The objective is to target 100% while formally retiring legacy “forever exemptions.” Launch a passwordless pilot (FIDO2/passkeys) for one admin team and one business cohort, and design risk-based authentication rules: allow on known user + managed healthy device; step-up for unmanaged/new device or privileged action; deny when multiple high-risk signals combine.
Fallbacks matter. Many estates mix devices, browsers, and legacy apps. Provide modern fallbacks (e.g., platform passkeys, OTP via authenticator app) with tight risk limits to prevent lockouts during the pilot. Begin migrating apps behind SSO and deprecate basic/legacy auth where feasible.
Reality check: Don’t flip every app in one week. Prove the pilot works, then schedule broader enablement during the 90-day scale-out.
Week 3: Least privilege and machine identities (Days 15–21)
Goal: Shrink blast radius and remove silent backdoors.
Use early CIEM insights to prioritize entitlement fixes. Full CIEM onboarding across clouds typically exceeds 30 days; for the MVP, focus on the top ten over-permissioned roles in one cloud or business unit and convert daily “admin” work to JIT elevation for sensitive tasks. Bind elevation to passwordless step-up and strict expiry.
Tackle machine identity security in parallel. Inventory NHIs, assign owners, and rotate long-lived keys where safe. When legacy workloads require static secrets, move them into a vault (e.g., HSM-backed solutions) with audit, tight scope, and rotation windows. Prefer short-lived, scoped tokens with audience restrictions as you modernize.
Reality check: Document exceptions with owners and expiry dates. The outcome this week is prioritized reduction, not perfection.
Week 4: Detection, automation & operating model (Days 22–30)
Goal: Make Zero Trust continuous without breaking things.
Enable Identity Threat Detection & Response (ITDR) detections for anomalous token use, rogue privilege grants, suspicious session patterns, and legacy protocol use. Introduce automated remediation carefully: start with low-risk actions like token revocation or forced re-auth before full account disablement. Build playbooks that attach rich context to tickets so analysts can confirm intent quickly.
Align TPV (Time to Patch Vulnerabilities) with MTTR so patches ship as fast as incidents are fixed, but treat the first month as instrumenting the metric and agreeing on P1/P2 targets, not achieving every SLO. Publish your operating rhythms: weekly metric reviews, monthly entitlement cleanup, and quarterly access certification.
Reality check: “auto-contain everything” is not a Week-4 goal. Scope automation where lockout risk is minimal; expand after two to three tuning cycles.
Zero Trust 2025: The dashboard that steers you
Use four lenses and keep each metric segmentable by app, team, and environment.
Coverage Track identity inventory coverage, admin MFA progress toward 100% with managed exceptions, passwordless pilot adoption, and Tier-1 SSO coverage. Set targets as directional in the MVP and convert to SLOs during the 90-day scale-out.
Reduction Show excess-privilege trending down, JIT replacing standing admin rights in the first target area, and dormant/orphaned identities decreasing. Log CIEM onboarding status and analysis depth so stakeholders see why the curve changes gradually.
Speed Instrument identity MTTD/MTTR and the TPV vs MTTR delta. In the MVP, focus on data quality and alert routing; hard targets come as tuning stabilizes.
Automation Report on low-risk auto-actions (token revokes, secret rotation) and on-time access reviews. Expand to higher-impact automation only after two clean weekly reviews.
Risks and real-world mitigations
Prompt fatigue is normal for a week or two; Risk-based authentication and passwordless should bring it down.
Legacy systems resist modern auth; isolate them behind SSO gateways and use identity orchestration to sequence migrations safely.
Cultural pushback eases when you show fewer prompts and fewer incidents on the same dashboard.
Scope creep is managed by sprint discipline. Don’t add apps without adding test time and a rollback.
The MVP keeps you moving: identity visibility, safer authentication with fewer interruptions, tighter privileges, and detections you can trust. Use this month to prove value, then expand by business unit and cloud over the next two to four quarters.
Rethinking identity for AI agents and other non-human identities – Unosecur
When a non-human identity such as an AI agent calls your systems, authentication and identity shift from human prompts to machine-centric interactions.
Non-human identities (NHIs) such as service accounts, workloads, bots, and agents authenticate by relying on policy and attestation rather than MFA credentials and demand short-lived, traceable credentials with full governance.
AI agents authenticate without people in the loop, often using their own identities, short-lived tokens, and policy decisions made in real time. As AI agents and automation become first-class participants across enterprise systems, identity must shift from MFA to machine-centric verification.
Prove software identity. Use attestation + mTLS (SPIFFE/SPIRE) so services prove what they are: code origin and runtime, not just that they hold a token.
Govern the lifecycle. Zero Trust requires least privilege, continuous policy, logging, ownership, rotation, and de-provisioning for all identities (human and machine).
Govern the lifecycle: ownership, least privilege, logging, and de-provisioning
Authentication is just the starting point of identity use. It covers everything from join/move/leave to real-time policy and evidence.
Zero Trust requires per-request authorization, dynamic policy, and continuous monitoring across all identities. For NHIs, that means: assign an owner; scope to least privilege; log every action; set expiries; rotate credentials; and de-provision when projects end. CISA’s ZT Maturity Model and NIST SP 800-207 both frame identity as continuous and policy-driven, not a one-time gate.
Operational controls to standardize
Ownership and metadata: owner, purpose, data sensitivity, environment.
Policy and scopes: minimal roles, JIT elevation where feasible, and per-session decisions.
Evidence and audit: API, token, and policy-decision logs tied to NHI identity; automated revocation on risk.
Why MFA doesn’t fit non-human identities
Before deciding “how” to secure bots and agents, clarify “who” is authenticating, and how that differs from a person.
Human MFA assumes an interactive user. NHIs authenticate non-interactively using app credentials or workload identities; applying human prompts (OTP, push, SMS) breaks automation and doesn’t add assurance about software provenance.
Major platforms explicitly support these app/workload flows (e.g., OAuth 2.0 client credentials for app-only access, and Entra Workload Identities to govern service principals). Zero Trust still applies, but the controls are policy, scope, and attestation, not MFA challenges.
What this means in practice
Use app-only flows (client credentials, mTLS) when no human is present.
Govern access with scopes/roles and Conditional Access equivalents for workloads (risk, attributes, environment), not human prompts.
When an agent acts for a human, issue delegated access tokens via OAuth; APIs are called with access tokens, not ID tokens. (Architectural pattern aligned with Zero Trust session-by-session decisions.)
Replace static secrets with federation and short-lived credentials
Static keys linger in code and infra, are hard to rotate, and create high-value secrets. Cloud providers offer first-class alternatives: AWS STS for temporary credentials; IAM Roles Anywhere for external workloads to obtain temporary AWS creds via X.509 trust; and Microsoft Entra Workload Identity Federation and Managed Identities to eliminate secret management and mint tokens at runtime.
These patterns shrink the blast radius and map cleanly to Zero Trust’s “never trust, always verify.”
What good looks like
Prefer AssumeRole/STS or managed identities over stored keys. Automate rotation by design because credentials are short-lived.
If workloads run outside your primary cloud, use Roles Anywhere (cert-based) or workload federation; add runtime attestation if you need to prove environment integrity.
Tag every NHI with owner, purpose, and expiry; deny tokens beyond task scope. (Supports future de-provisioning and audit.)
Prove software identity with attestation, mTLS, and SPIFFE
Short-lived tokens limit time-based risk; proving what is holding the token tackles identity risk at its root.
SPIFFE/SPIRE establish cryptographic workload identity via SVIDs and deliver short-lived, automatically rotatedX.509 credentials for mTLS between services. SPIRE performs node and workload attestation so identities reflect runtime properties (where and how the workload runs). Combined with policy (which service can talk to which), this gives you machine-native assurance far beyond “token possession.”
Implementation notes
Use SPIRE or equivalent to issue SVIDs; terminate TLS only where necessary to preserve end-to-end identity.
Bind authorization decisions to attested identities plus request context (namespace, image digest, node labels).
In a nutshell
Securing non-human identities means swapping human prompts for automation-native identity: app/workload flows, short-lived credentials, workload attestation + mTLS, and full lifecycle governance. Done well, this reduces standing privilege, shrinks the blast radius, and produces audit-ready evidence that each machine action was both trusted and policy-compliant, exactly what modern Zero Trust guidance prescribes.
Non-Human Identity Security in the Age of AI – GitGuardian
The rise of AI in enterprises has expanded the attack surface. Learn how GitGuardian can help you secure non-human identities and prevent unauthorized access.
It is not a coincidence that non-human identities (NHIs) have come into focus recently while AI-powered tools and autonomous agents are rapidly being adopted. In fact, this is partially what is driving the explosion of NHIs in the enterprise. This has sparked a lot of research and conversations about machine identity and governance.
Like human users of systems, NHIs, such as AI agents, bots, scripts, and cloud workloads, operate using secrets. These credentials grant access to sensitive systems and data. They can take many forms and must always be accounted for, from creation to offboarding. Unlike humans, machines can’t use multifactor authentication or passkeys, and developers can generate hundreds of these credentials through their work deploying applications.
The adoption rate for AI in the enterprise has been staggering, driving developers to roll out NHIs faster than ever. AI brings with it an opportunity to help us get a lot more done more efficiently, but it also brings some real risks around privacy, secrets exposure, and insecure code. There are some amazing use cases for LLMs, but we need to remember that, like any technology, the more you add to your environment, the larger the attack surface grows. This is especially true when we give agency to these AI agents.
The time to tackle NHI security in your increasingly AI-powered organization is now. Let’s take a look at some of the risks associated with AI agents NHI’s.
The NHI Risks From AI
AI Agents and Secrets Sprawl
“AI agents” are LLM-based systems that decide independently how to accomplish a specified task. These are not the deterministic bots we have been using with many workflows for years, which can only perform the specific instructions the developer laid out step by step. These AI agents can access internal data sources to look up information, search the internet, and interact with other applications on behalf of the user.
For example, an AI-powered procurement agent could analyze purchasing needs, compare vendors through online shopping sites, negotiate prices with AI chatbots, and even autonomously place orders if allowed. Every secure communication requires access credentials. This new agent is produced through a DevOps process, requiring even more authentication across the pipeline. Credentials commonly, accidentally, get scattered across systems, logs, and repositories along the way.
It is very common to grant AI agents wider read, write, and even creation and deletion permissions than we would for deterministic bots. For traditional machine workers, we define what systems they can and can not access as part of the work we assign them to accomplish. Since AI agents are left to determine the best path for completing the job without direct supervision, we block the requested work if we scope our access too tightly. What read and write permissions will be required might not be clear from the beginning, and many teams are erroring on the side of being too permissive.
A leak of any one of the many keys involved could lead to a data breach or unauthorized purchases, among other risks. Strong Non-Human Identity governance is essential to secure these AI agents. For all known and properly stored credentials in your vaults, enforce least privilege access, API key protection, and audit logging to prevent exploitation. Your strategy also needs to account for secrets that will undoubtedly be found outside of your vaults as well.
Orphaned API keys
An orphaned API key is an API key that is no longer associated with a user account. This happens when a user leaves a company or deletes their account. Any API keys they made stay valid, but now, no one owns them, and unless properly accounted for, they are likely to never get rotated or deleted.
In the world of machine identities, the question of who owns an NHI is a tricky one. Is it the person who created it? A dedicated DevOps team? Without clear ownership, the likelihood of a credential becoming orphaned and forgotten yet still allowing access is very high.
A better question would be, who owns the risk associated with a breach caused or aided by these API keys?
Prompt-Based Architecture and Sensitive Data Exposure
When we think of an AI assistant, we immediately think of players like ChatGPT, Gemini, and Claude, all of which use prompt-based architectures. So does GitHub Copilot. The AI models process, store, and transmit sensitive information through prompts, sending context, commands, and data to a large language model (LLM) provider. This approach makes these tools exceptionally easy to interact with, leading to rapid prototyping and tool development.
This is not isolated to your development teams. In fact, as we see shadow IT become the majority of the IT spend in many organizations, the real risks of data exposure, proprietary business data, and credential leakage spread throughout the whole of the enterprise.
For example, if a finance team uses an AI-powered chatbot to automate invoice processing, and their prompt contains Find all invoices over $100,000 in the past 6 months using API key ABC123, that API key will most likely now be logged. If those logs are left in plaintext, they would allow an attacker unauthorized access to that invoicing system. Hopefully, that key is properly scoped.
Safeguards need to be put in place to prevent developers and all users from embedding sensitive data in prompts and logs. Ideally, each LLM output can be scanned for information that should not be there. While defining what returned data is sensitive can be tricky, finding and eliminating secrets should be straightforward and prioritized.
AI Agents and Data Collection Risks
AI agents often ingest, process, and store data from various sources, including:
Cloud storage such as AWS S3 and Google Drive.
Enterprise applications like Jira, Confluence, and Salesforce.
Messaging systems, including Slack and Microsoft Teams.
We need to work to keep all sensitive information, such as credentials, PII, or other private data, out of these systems. If your AI agent can access any data in these systems, then the path for an attacker to abuse this NHI also exists.
The only sure way to eliminate this attack vector is to find and rotate any and all keys found throughout all internal systems around any AI agents. This includes version control systems, ticketing systems, and messaging platforms. Combined with good log sanitation, this can go a long way to keeping your secrets secret.
AI-Generated Code and Embedded Secrets
AI-powered development tools like GitHub Copilot, Amazon CodeWhisperer, and Tabnine, have seen a rapid rate of apodtion. Today, over 50% of developers use AI copilots to assist with coding. These tools auto-generate code snippets based on vast amounts of training data. However, this introduces a major security risk, as AI-generated code may mislead a busy developer to hardcode secrets, such as API keys, database credentials, and even OAuth tokens.
For an example of an AI-generated risk, imagine a developer asks Copilot to generate an API call to a cloud service, and it produces:
While that is not a real key, a developer under a time crunch or who is not familiar with secrets security might just swap a real key for the generated one. If left unchecked, such code may get committed to version control systems, exposing credentials to attackers who gain access or anyone if the repo becomes public.
This pattern is part of how secrets sprawl has continued to get worse over time. We need to help developers with guardrails that help speed them along while scanning all code before committing it, as you can do with GitGuardian’s ggshield and pre-commit hooks. Ideally, they can catch the secret before they even perform a git add using our VSCode extension, which finds secrets when the file is saved.
The Path Forward: Securing Non-Human Identities
The first step toward getting a handle on the NHIs in your organization is finding out which secrets you have. The GitGuardian Non-Human Identity Security platformcan automatically discover AI-agent credentials across enterprise environments. Parting with enterprise secrets management platforms like CyberArk’s Conjur, we can find all secrets inside and outside your vaults, accounting for them wherever they are and helping you properly move them to the right place.
Getting an accounting of these NHI credentials is the first step, but just finding a plaintext key does not tell you much about what is at risk. You still need to figure out where it goes, how it can be used, and what critical systems are accessible. This is why we introduced GitGuardian’s Secret Analyzer, which automatically shows the assigned permissions of key, helping you remediate over-permissioned secrets quickly.
Understanding the secrets and mapping how they interconnect will give you the insights you need to understand what each secret connects to and help you understand what is at risk if exposure does occur.
GitGuardian can also prevent sensitive data from being embedded in prompts or logs. Finding these incidents in real-time can help you ensure sanitation is happening and logs are not as helpful to an attacker.
Getting your NHI governance strategy ready for the speed of AI.
There are no guarantees about what AI agents will ultimately deliver, but it is clear it is going to happen at a very accelerated pace. The complexity we are introducing now to deploy self-guiding AI agents to interact with other systems and agents brings with it a number of perils and a lot of promise for working more efficiently We are here to help you navigate forward securely as you add more NHIs faster than ever. From automated secrets scanning to giving you insights into what your NHIs can access and with which privileges, GitGuardian is helping enterprises manage and secure non-human identities at scale.
ISO 27001:2022 Requirements Explained for 2025 – Teleport
ISO/IEC 27001:2022 provides a framework for managing information security using an Information Security Management System (ISMS).
The October 2025 deadline to upgrade from the previous ISO 27001:2013 standard is coming fast, and organizations yet to transition risk losing their certification. Maintaining ISO/IEC 27001 certification is especially relevant for regulated industries, SaaS providers with enterprise customers, and global organizations handling sensitive data.
In this blog, we break down ISO 27001 requirements in 2025, what’s changed from 2013 to 2022, and how Teleport can help simplify ISO compliance and accelerate the journey to new or re-certification.
Understanding ISO 27001 Certification in 2025
The International Standards Organization regularly updates the requirements of ISO 27001 every five years. The most recent edition, ISO 27001:2022, retains the core structure of ISO 27001:2013’s primary management clauses and Annex A controls, with updates to reflect the modern risk landscape.
Organizations have until 31st October 2025 to complete the migration from ISO 27001:2013 to ISO 27001:2022. After this deadline, prior certifications will expire.
Whether you’re pursuing initial certification or upgrading from 2013, you’ll need to define your scope, engage leadership, allocate resources, set measurable objectives, and apply the right controls to meet audit expectations. ISO 27001:2022 formalizes these requirements across 11 main clauses and a refreshed set of Annex A controls.
Clauses 0 through 10 comprise the ISO/IEC 27001:2022 standard. However, Clauses 4-10 contain formal certification requirements and are the focus of the audit process. These auditable clauses define how to establish, implement, maintain, and continually improve an ISMS in alignment with ISO 27001 expectations.
This includes:
Clauses 0-3: An Introduction to ISO 27001:2022
Clause 4: Context of the Organization
Clause 5: Leadership
Clause 6: Planning
Clause 7: Support
Clause 8: Operation
Clause 9: Performance Evaluation
Clause 10: Improvement
Each auditable clause (4-10) is assessed during certification for both documentation and effectiveness. This means clause-by-clause readiness is critical to ensure audit and certification success.
Below, we’ll summarize the key takeaways from each clause, alongside examples of what those clauses can look like in practice.
Clauses 0-3: An Introduction to ISO 27001:2022
These clauses outline the purpose, structure, and terminology of the standard. Clause 0 introduces ISO’s risk-based approach; Clause 1 defines the standard’s scope; Clauses 2 and 3 provide key references and definitions.
While these sections do not outline specific requirements, familiarizing yourself with these introductory clauses is highly recommended for those new to ISO 27001, or for those simply looking for a refresher on the standard.
For the purposes of this blog, we will skip the first three clauses and jump to Clause 4.
Clause 4: Context of the Organization
Clause 4 requires defining the scope of your ISMS and identifying internal and external factors that influence your organization’s information security. This includes applicable laws, industry frameworks (like NIST or CIS), contractual obligations, or infrastructure threats.
Clause 4.3 specifically requires a documented “scope of the ISMS,” requiring organizations to outline the systems, people, processes, and geographic locations of their ISMS. This scope feeds into the Statement of Applicability (SoA), which documents the Annex A controls being implemented or excluded, along with explanations of why and why not.
Example – Clause 4 in action:
A healthcare company might include HIPAA and data localization laws in its context analysis. A cloud SaaS company might include SOC 2 and customer SLAs. These inputs should reflect both regulatory obligations and business risk drivers, which also feed into Clause 6’s risk planning.
Defining too broad or too narrow a scope can lead to audit challenges or operational blind spots. Aim for clear, justifiable boundaries tied to business function and risk exposure.
Clause 5: Leadership
Clause 5 requires senior leadership to demonstrate accountability for the ISMS. This is achieved by publishing an information security policy (Clause 5.2), assigning roles and responsibilities (Clause 5.3), and embedding the ISMS practices into business operations.
Clause 5.3 connects directly to Annex A control A.5.1 (Information Security Policies), requiring that these documents be maintained, communicated, and regularly reviewed.
Example – Clause 5 in action:
The CISO signs the information security policy, the CTO is designated as the ISMS owner, and business unit leads are assigned responsibility for reviewing access to systems in their domains. Evidence of this can include org charts, role descriptions, and meeting records.
Auditors will often request proof that leadership has not only approved policies, but actively participates in review cycles and corrective actions.
Clause 6: Planning
Clause 6 focuses on identifying risks and opportunities, setting measurable objectives, and establishing formal plans for treatment mitigation.
Clause 6.1.2 requires a formal risk assessment process with criteria for evaluating likelihood and impact. Clause 6.1.3 then requires a documented risk treatment plan to specify which controls from Annex A will be used to mitigate identified risks, along with a justification for each choice.
Clause 6.2 requires defining measurable security objectives. An example objective could be: “Reduce the mean time to revoke access after a role change to under two hours by Q3.” This can be tracked and verified through audit logs and system integration reports.
Example – Clause 6 in action:
If a company identifies standing SSH access as a risk, it may select control A.8.2 (Privileged Access Rights) and document this in the risk treatment plan and SoA.
Audit success depends not only on defining objectives but showing ongoing measurement and outcomes tied to them.
Clause 7: Support
Clause 7 ensures that your ISMS is supported by the right people, training, communications, and documented information. Clause 7.2 focuses on competence, ensuring that staff involved with the ISMS have appropriate training. Clause 7.4 requires a communication strategy for both internal and external parties.
Clause 7.5 also introduces documentation control requirements. All ISMS-related records such as policies, audit logs, risk assessments, and the SoA must be version-controlled, securely stored, and easily retrievable.
Example – Clause 7 in action:
Organizations might maintain training logs showing that engineers completed secure coding and zero trust access management training courses.
Make sure training records are tied to job roles, and that your documentation system supports version history and traceability.
Clause 8: Operation
Clause 8 governs the execution of your ISMS by requiring that risk treatment plans are implemented, monitored, and continually evaluated.
Clause 8.1 calls for operational planning and control. This includes maintaining an up-to-date risk register and documenting how risks are managed, monitored, and reassessed with clear evidence of control implementation. If Annex A controls are used, their implementation must be documented, assigned to owners, and actively monitored.
Example – Clause 8 in action:
If an organization treats the risk of leaked credentials with control A.5.17 (Authentication Information), it must provide logs of certificate issuance, expiration, access revocation, and control ownership to demonstrate effective operational control. These are operational outputs of the ISMS that demonstrate ongoing enforcement and review.
ISO auditors will ask to trace each control back to a specific risk and see evidence of that control functioning in daily operations.
Clause 9: Performance Evaluation
Clause 9 formalizes how ISMS performance must be evaluated through internal audits (9.2), management reviews (9.3), and ongoing monitoring of controls and objectives (9.1). Each activity must be scheduled, repeatable, and backed by documented outputs that demonstrate whether the ISMS is operating as intended.
Example – Clause 9 in action:
If an organization treats the risk of leaked credentials with control A.5.17 (Authentication Information), it must provide logs of certificate issuance, expiration, access revocation, and control ownership to demonstrate effective operational control. These are operational outputs of the ISMS that demonstrate ongoing enforcement and review.
Auditors will expect to see clear evidence of internal audits and management reviews, with decisions and corrective actions documented for traceability.
Clause 10: Improvement
Clause 10 is about managing nonconformities (10.1) and driving continuous improvement (10.2). When controls fail or are bypassed, the root cause must be analyzed, corrective actions documented and implemented, and results independently verified where possible.
Example – Clause 10 in action:
If an access review reveals a terminated employee still had database access, the organization would log the incident and perform root cause analysis on the HR-to-identity sync process. The improvement action would involve updating the provisioning workflow and validating that access is correctly revoked in future cases.
This improvement cycle links back to Annex A controls such as A.5.24 (Incident Management Planning and Preparation) and A.5.27 (Learning From Security Incidents).
A functioning Clause 10 process is what distinguishes mature ISMS implementations from paper-compliant ones. Auditors will look for a closed-loop corrective action process with detailed evidence of follow-through.
Does ISO 27001:2022 Have Control Requirements?
Annex A of ISO/IEC 27001:2022 outlines 93 security controls that organizations can implement as part of their Information Security Management System (ISMS). These controls span four categories: People, Organizational, Technological, and Physical.
While Annex A does not require implementation of all 93 controls, it functions as a reference framework to guide risk treatment planning. Organizations must complete a Statement of Applicability (SoA) to document whether each control is implemented, the rationale behind its inclusion or exclusion, and how each selected control is applied.
In practice, Annex A serves as a structured reference to align technical, operational, and policy-level controls with ISO 27001’s broader risk treatment framework, but it should not be treated as a one-size-fits-all checklist.
What Annex A Controls Are New in ISO 27001:2022?
The 2022 update introduced several new and revised controls to address evolving risks related to cloud-native infrastructure, hybrid workforces, decentralized identity, and increased automation.
Teleport supports alignment with many of the updated controls in ISO 27001:2022, particularly those focused on identity, access, audit, and automation. This is documented in the table below.
Revised/New ISO 27001:2022 Control
How Teleport Supports Alignment
A.5.7 Threat Intelligence
Generates real time and historical logs exportable to SIEMs for threat correlation and analysis.
A.5.23 Information Security for Use of Cloud Services
Centralizes access control across cloud environments (AWS, GCP, Azure, Kubernetes) using short-lived certificates and just-in-time provisioning.
A.5.30 ICT Readiness for Business Continuity
Enables secure access and session logging during infrastructure outages to support operational continuity in distributed environments.
A.8.9 Configuration Management
Audits and controls access to infrastructure configuration tools such as Terraform, Kubernetes, and CI/CD systems.
A.8.12 Data Leakage Prevention
Limits access exposure using time-limited certificates and role-based access to sensitive systems.
A.8.16 Monitoring Activities
Enables real time monitoring of active sessions, including view, pause, and termination capabilities for audit and compliance oversight.
Looking for a more detailed ISO 27001 control mapping?
Discover how Teleport applies to key Annex A controls, including secure access, real time audit logging, automated identity governance, and more.
ISO/IEC 27001 is not mandatory. But for any security-conscious organization, certification can be a major strategic advantage.
Most customers, partners, and regulators expect you to protect sensitive data with clear, auditable controls. ISO 27001 proves that you can, and that your security posture is built to withstand real world threats. That’s part of the reason Teleport maintains our own ISO certification, assisted through the use of our Infrastructure Identity Platform.
Teleport simplifies ISO 27001:2022 implementation by removing standing access, eliminating static credentials, and unifying access control across environments. No more secrets to manage. No bastion infrastructure to maintain. Just one platform designed to make meeting key identity, access, and audit requirements simple.
Just as we help simplify ISO/iEC 27001 compliance, Teleport also maps to key requirements across standards and regulations like FedRAMP, SOC 2, HIPAA, PCI, NIS2, DORA, and much more.
Reflections on Identiverse 2025: Identity Is the New Perimeter. So Why Are the Ports Still Wide Open? – Clarity Security
“Identity is the new perimeter.” It’s the default mantra of the cloud era—and for good reason. With remote work, SaaS sprawl, and distributed infrastructure, users, apps, and data now live everywhere. Identity is the one constant security teams can anchor to. But here’s the catch: If identity is the perimeter, then access governance is your firewall. And for most orgs? That firewall is full of open ports.
What Do We Mean by “Open Ports”?
Every excessive entitlement. Every stale account. Every unused group membership.
That contractor who left six months ago but still has admin rights in Okta? Open port.
That over-permissioned service account sitting idle? Open port.
Access may be invisible, but its risks aren’t. And far too many teams don’t know how wide their blast radius really is.
The Governance Gap
At Identiverse last week, one theme came up again and again: “We have identity tooling, but we’re not governing all of it.” SSO, MFA, conditional access—these are table stakes. They secure the front door. But what happens after a user gets in? That’s where most programs fall short.
Many orgs are running what we’d call “IGA Lite.” Some reviews here. A custom workflow there. But visibility is siloed, access reviews are manual, and decisions lack context. This isn’t about blaming overwhelmed teams—it’s about naming the pattern. Governance has become the firewall we forgot.
Context Is the New Control Plane
To secure the access layer, we need to move from static rules to adaptive decisions.
It’s time to ask:
Is this access being used?
Does it map to the person’s actual role?
Who owns it—and who’s reviewing it?
You don’t need 12 overlapping tools. You need clarity—a unified model that brings identity, access, and context together in one place.
Identity is the perimeter. But governance is what determines how far the blast spreads.
