SSH keys may be the riskiest credentials you’re not thinking about. In today’s DevOps pipelines, GitLab SSH keys silently facilitate critical operations—from pushing code to deploying infrastructure. 

Just because GitLab SSH keys are unassuming doesn’t mean you should ignore them. Unlike passwords, SSH keys don’t trigger alerts when reused, leaked, or silently exploited. Unfortunately, attackers know this, too. 88% of all web application attacks involved stolen credentials. Last year, 2.8 billion passwords appeared for sale on the dark web.

Whether you’re a developer committing code or a platform engineer automating CI/CD, poorly managed SSH keys open the door to unauthorized access and untraceable changes.

What are SSH keys, and why do they matter for GitLab?

SSH (Secure Shell) keys are a cryptographic authentication method for establishing secure, encrypted connections between systems. Instead of relying on usernames and passwords, SSH keys allow for more secure, automated authentication.

An SSH key pair consists of two parts:

• A public key is shared and stored on the remote server (like GitLab).
• A private key, which remains securely stored on the user’s machine. 

When you connect to GitLab, your private key proves your identity without ever sending a password over the network. SSH keys are commonly used to securely push and pull code from repositories, automate deployments, and enable CI/CD tools to access Git projects without manual credential handling. 

For developers and platform engineers, SSH keys reduce friction while maintaining security—but there’s a catch: SSH keys only work as intended if they’re managed properly. Poor SSH key hygiene (e.g., reusing keys, not rotating them, or storing them insecurely) opens the door to credential abuse and unauthorized code changes.

Understanding Non-Human Identities (NHIs) in GitLab

While SSH keys are often associated with developers, many are used by non-human identities (NHIs), such as CI/CD tools and infrastructure bots. These machine identities require access to GitLab repositories to complete tasks like syncing code or running builds.

Managing these identities securely is part of machine identity management (MIM). Each NHI should have precisely scoped, temporary access, just like a human user. Poor oversight of NHI credentials, especially static SSH keys, can expose your pipelines to serious risks, such as unauthorized code changes or lateral movement within your infrastructure.

It’s not just a vague possibility—these attacks occur in real life. In 2023, Microsoft exposed a Shared Access Signature (SAS) token granting full access to 38TB of internal data, including personal chats and documents. The long-lived token, a form of NHI, lacked expiration and proper access scoping. Similarly, BeyondTrust suffered a breach in 2024 due to an overprivileged API key that enabled attackers to escalate privileges across systems via a chained vulnerability.

How to Use SSH Keys to Communicate with GitLab

To securely access GitLab repositories using SSH, you need to generate an SSH key pair, add the public key to GitLab, and configure your local environment. Below is a step-by-step guide to get you up and running.

1. Generate an SSH Key Pair for Your GitLab Account

Use the following command to generate a new key pair:

ssh-keygen -t ed25519 -C “[email protected]”

If ed25519 isn’t supported on your system, fallback to:

ssh-keygen -t rsa -b 4096 -C “[email protected]”

When prompted:

• File location: Press Enter to save it to the default location (~/.ssh/id_ed25519). If a key already exists at that location, this will overwrite it. Use a custom filename to avoid this if you’re managing multiple keys.
• Passphrase: Choose a strong, unique passphrase for enhanced security.

This step creates two files:

• id_ed25519 (private key – keep secure)
• id_ed25519.pub (public key – safe to share)

Pro tip: Use a custom filename if managing multiple keys (e.g., id_gitlab).

2. Add Your Public Key to GitLab

Make sure you install xclip if you haven’t already (e.g., for Linux systems). 

Copy the public key to your clipboard:

cat ~/.ssh/id_ed25519.pub | pbcopy   # macOS
xclip -sel clip < ~/.ssh/id_ed25519.pub   # Linux
clip < ~/.ssh/id_ed25519.pub   # Windows (Git Bash)

In GitLab:

1. Go to User Settings → SSH Keys.
2. Paste the key into the Key field.
3. Set an expiration date to enforce periodic key rotation.
4. Click Add key.

Security tip: Set an expiry date for each SSH key, especially for contractors or ephemeral environments.

3. Configure the SSH Agent

To avoid entering your passphrase each time, you can load your private key into the SSH agent.

eval “$(ssh-agent -s)”
ssh-add ~/.ssh/id_ed25519

If you’re using a custom filename or key path, specify it accordingly.

Troubleshooting: If ssh-add returns an error, ensure your private key file has the correct permissions (chmod 600 ~/.ssh/id_ed25519) and that the SSH agent is running.

4. Test Your SSH Connection to GitLab

Verify the setup with:

ssh -T [email protected]

You should see:

Welcome to GitLab, @yourusername!

If prompted to trust the GitLab server fingerprint, type yes. This step adds GitLab to your known_hosts file.

Common issues:

• Permission denied: Double-check if the correct key is loaded (ssh-add -l).
• Wrong key used: Force usage of the right identity by editing your ~/.ssh/config:

With these steps complete, your machine is securely configured to communicate with GitLab via SSH—ideal for Git operations, automation scripts, and CI/CD workflows. Next, let’s make sure your keys are properly secured and managed.

10 Best Practices for Securing GitLab SSH Keys

Using SSH keys with GitLab significantly enhances the security of your development workflows—but only if they’re managed properly. Here are ten best practices to ensure your SSH keys remain secure and effective.

1. Use Strong, Modern Key Types

Avoid outdated algorithms like DSA. Instead, generate keys with stronger encryption standards like:

ssh-keygen -t ed25519 -C “[email protected]”

Or, if you need broader compatibility:

ssh-keygen -t rsa -b 4096 -C “[email protected]”

The ed25519 type is preferred for its speed and security.

2. Protect Your Private Key with a Passphrase

Always add a strong, unique passphrase when generating your SSH key, which ensures that even if someone obtains your private key file, they still can’t use it without the passphrase.

To change or add a passphrase to an existing key, use:

ssh-keygen -p -f ~/.ssh/id_ed25519

For long-running sessions, tools like ssh-agent or gpg-agent can securely cache your passphrase in memory so you don’t have to re-enter it constantly. If the passphrase is forgotten, the key becomes unusable and must be regenerated.

3. Store Private Keys Securely

Never commit your private SSH key (id_ed25519 or id_rsa) to Git or store it in publicly accessible locations.

Use encrypted disk storage or a password manager that supports file attachments for backup—this applies not just to SSH keys, but also to secrets used in API security contexts.

Set correct file permissions:

chmod 600 ~/.ssh/id_ed25519

4. Use One Key Per Device

Generate a unique SSH key pair for each device you use to access GitLab. This step allows you to revoke a single key if the device is lost or compromised without affecting access from other systems.

GitLab allows you to associate multiple SSH keys with your account. Use unique names to keep track of each device and manage them independently.

5. Rotate Keys Periodically

Regularly rotate your SSH keys, particularly if they’ve been used for a long time or if you suspect they may have been exposed. It involves:

• Removing the old public key from GitLab.
• Generating a new pair.
• Adding the new public key.

Consider automating SSH key rotation using a centralized access management platform like Apono, which can enforce short-lived access and eliminate the risks of stale credentials, especially in ephemeral or short-term environments.

6. Restrict SSH Key Usage

If you’re managing a shared GitLab instance or have admin rights:

• Use GitLab deploy keys for CI/CD or automation tasks.
• Grant keys only the access level they need (read-only vs. read/write).
• If required, use GPG signing in addition to SSH for commit verification. To ensure commit authenticity, consider enabling GPG signing for commits alongside SSH-based repository access.

Keep in mind that deploy keys in GitLab are tied to individual projects and can be granted read-only or read/write permissions. Be cautious when enabling write access, especially for automation tasks. 

For CI/CD pipelines and automated processes, you’re not managing human users—you’re securing machine identities. These non-human identities often need access to multiple environments but pose risks if granted persistent, broad permissions. It is especially important when pipelines include tasks like testing, deployment, or code generation, which require secure, scoped access to your GitLab repo.

Managing SSH keys for NHIs requires automation, auditability, and temporary access control—capabilities built into platforms like Apono, which help enforce just-enough, time-bound permissions for both humans and machines.

7. Monitor and Audit Key Usage

Regularly review the list of SSH keys in your GitLab account:

• Navigate to User > Preferences > SSH Keys (depends on GitLab version/edition).
• Check for unfamiliar keys or outdated entries.
• Remove keys that are no longer in use.

GitLab’s audit events and API endpoints can help automate SSH key inventory and alerting. For a more comprehensive view across cloud infrastructure and CI/CD workflows, platforms like Apono offer centralized logging, real-time auditing, and granular insight into how SSH credentials are used, granted, and revoked. Take a leaf out of Okta’s book for what not to do—in 2023, the company experienced a breach through a compromised service account (a type of non-human identity), exposing sensitive customer data. 

In addition to routine audits, periodic penetration testing can help uncover misconfigured SSH key permissions and exposed keys.

8. Avoid Using SSH Keys on Shared Machines

Never store your private SSH key on a shared or public system. If you’re using such a machine, consider temporary access tokens or Git over HTTPS instead.

Use ssh-add -l to verify that your key is currently loaded into the agent. If you’re using a custom key path, don’t forget to specify it when adding the key.

9. Use an SSH Agent for Convenience and Security

An SSH agent lets you enter your passphrase once per session and keeps your key in memory, minimizing repeated exposure. On Windows, enable the agent via:

#Powershell
Set-Service -Name ssh-agent -StartupType Manual
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

On macOS and Linux, use:

#Bash
eval “$(ssh-agent -s)”
ssh-add ~/.ssh/id_ed25519

10. Disable Inactive Accounts Promptly

If a contributor leaves your team, remove their SSH keys immediately from GitLab to prevent unauthorized user access. Integrate SSH key deactivation into your offboarding workflow using GitLab’s user management API. In enterprise settings, consider syncing GitLab with your access management platform (whether Apono or others) to automate removing access when HR systems disable a user.

Taking GitLab SSH Security Further with Apono

SSH keys are a foundational element in securing access to GitLab repositories. By replacing password-based logins with strong public-private key cryptography, SSH keys ensure that only verified users and systems can interact with your codebase. Whether you’re working on personal projects or managing enterprise-scale infrastructure, using SSH keys properly is essential for maintaining secure and efficient developer workflows.

In this guide, we’ve covered:

• What SSH keys are and why they matter.
• How to generate, configure, and use SSH keys with GitLab.
• Troubleshooting tips and hardening best practices.

Apono automates and governs access to GitLab and other tools with Just-In-Time (JIT) workflows, ephemeral credentials, and auto-expiring permissions. Instead of long-lived keys sitting unused (and vulnerable), Apono grants precisely scoped access when needed, and revokes it when it’s not. This eliminates standing privileges, enforces least privilege, and shrinks your attack surface.

With Apono, you can:

• Replace static SSH key management with dynamic, audited access.
• Apono integrates with GitLab to govern access at the repository and deployment level—ideal for securing CI/CD pipelines, GitOps workflows, and service-to-repo automation. 
• Automatically revoke access when it’s no longer needed—no manual cleanup required.
• Users can request and receive SSH access directly from Slack, Teams, or the CLI—no tickets, no waiting, and full auditability.

Don’t let SSH keys become your weakest link. Pair them with Apono to automate access, enforce least privilege, and stay audit-ready at scale.Ready to eliminate standing access and secure GitLab at scale? Book a personalized Apono demo and see how JIT access can transform your security posture.

Machine identities have quietly become the backbone of digital infrastructure, outnumbering human users in most enterprise environments. While they don’t forget passwords or call tech support, they do introduce a unique set of security and operational risks.

Unlike human users, machine identities (like service accounts, API keys, bots, and microservices) often operate with highly permissive access rights and weak or nonexistent authorization policies. Machine identity management (MIM) brings clear security and compliance benefits when managed well. Without it, you face security risks like orphaned credentials and shadow identities. 

Yet, for many organizations, machine identity management remains an afterthought. 69% of companies now manage more machine identities than human ones, but 72% admit that managing them is more difficult due to poor internal processes and inadequate tools. Taking control starts with machine identity management best practices, which we will explore in this article. 

What is machine identity management, and why does it matter?

Machine identities are credentials used to authenticate and communicate with each other. These identities include API keys, code secrets, SSH keys, and certificates. Non-human identities (NHIs) must be audited, authenticated, and authorized like human user accounts. 

Machine identity management encompasses the processes, tools, and policies used to discover, categorize, assign ownership, monitor, rotate, and revoke the credentials of machine identities. It involves managing the identities themselves, enforcing least privilege principles, and securing the integrity and trustworthiness of machine-to-machine communication. MIM ensures proper authentication while enabling full observability and a layer of trust for workloads (apps, APIs, and containers) and physical devices (IoT devices and mobile endpoints) alike.

What is the machine identity management lifecycle?

Machine identity lifecycle phases include creation, provisioning, credential issuance, usage monitoring, rotation, deprovisioning, and revocation. Each phase must be auditable and automated to maintain least privilege and compliance.

Why does machine identity management matter?

Today, machine identities in organizations outnumber human ones by as many as 1 to 45, yet many businesses admit to having little to no oversight over them. This gap exists because traditional IAM solutions often overlook machine identities, leaving many undiscovered, unmanaged, or misconfigured. 

These shadow machine identities are prime targets for attackers, who can exploit them to move laterally across networks, exfiltrate sensitive data, or disrupt critical systems—all without triggering traditional security alarms. To close this gap, you have to shift your focus to modern identity-first security strategies that treat machine identities with the same rigor as human ones, incorporating best practices like continuous discovery, policy enforcement, and automated lifecycle management. We’ll explore these strategies and more later in the article. 

With effective machine identity management practices in place, you can reduce the risk of a breach while supporting compliance efforts in today’s dynamic environments, where cloud services and machine identities scale far faster than InfoSec teams can keep up.

4 Critical Threats to Machine Identity Management

As your organization scales, so does the sprawl of machine identities. The most critical hurdles impacting machine identity management today include:

1. Overprivileged Access

Developers often (wrongfully) assume that machine identities will only perform what other systems instruct them to do, never straying beyond their intended scope or falling into the wrong hands. As a result, machine identities and non-human identities are frequently granted broad permissions. Over-permissioning increases the blast radius in the event of a compromise, allowing attackers to infiltrate your systems and access sensitive data. 

Example Threat

A harrowing example is the 2024 BeyondTrust API key breach, attributed to a lack of credential rotation and excessive access. 

2. Lack of Observability

You can’t manage or audit machine identities you can’t see. Without real-time monitoring and robust logging policies, detecting suspicious activity tied to machine identities becomes almost impossible—often until it’s too late. Additionally, enforcing compliance across systems becomes a major challenge without a well-maintained catalog of all machine identities. This lack of visibility creates fertile ground for other risks, such as shadow machine identities and privilege creep. 

Example Threat

Just look at what happened during the 2023 Okta support system breach, in which attackers leveraged a poorly monitored service account. 

3. Shadow Machine Identities

Untracked and unmanaged machine identities include API keys, certificates, and service accounts that operate outside the visibility of security teams. When compromised, they often trigger no alerts. Undetected by traditional IAM tools, these rogue identities serve as ideal entry points for threat actors. 

Example Threat

The 2023 Microsoft SAS token leak is a perfect example of how a long-lived token functioned as a shadow machine identity with no expiration or oversight. 

4. Lifecycle Management Inconsistencies and Policy Drift

As annoying as it can be, human users are usually required to reset passwords periodically, enforced by IAM policies. However, machine identities often lack a clear owner and rely on static credentials that can remain unchanged for months or even years. 

Because machines don’t go through standardized onboarding or offboarding, their lifecycle is rarely managed consistently like humans in an organization. This results in the sprawl of zombie services, orphaned credentials, policy drift, and unauthorized access, all weakening your overall security posture. 

Example Threat

You only need to look at the 2024 Internet Archive Zendesk exposure for a warning on how unrotated, static tokens and ungoverned lifecycle practices can expose systems. 

Table 1: MIM Threats and Examples

Threat	Description	Real World Example
Overprivileged access	Machine identities are often granted excessive permissions under the assumption they will behave predictably.	BeyondTrust API Key Breach (2024): Involved an overprivileged, static API key that was exploited due to a lack of rotation.
Lack of observability	Without visibility, real-time monitoring, or logging, it’s nearly impossible to detect NHI misuse.	Okta Support System Breach (2023): Attackers used a poorly monitored service account to gain unauthorized access.
Shadow machine identities	Unmanaged identities, such as API keys or certificates that exist outside of IAM visibility. When compromised, they are rarely detected and easily exploited.	Microsoft SAS Token Leak (2023): A long-lived token granted full access to Azure data without expiration or oversight.
Lifecycle management inconsistencies and policy drift	Unlike human accounts, machine identities often have static credentials and no consistent lifecycle processes.	Internet Archive Zendesk Exposure (2024): Unrotated static tokens enabled attackers to access hundreds of thousands of support tickets.

5 Best Practices for Discovering, Securing, and Managing Machine Identities

Fortunately, these threats can be mitigated. Organizations that apply these foundational MIM best practices can regain control, reduce risk, and move closer to zero trust.

1. Less is Best: Minimize Machine Identity Privileges

Most security incidents and breaches stem from one root issue: excessive access privileges. It can be a long-forgotten service account with admin rights or an API key left in a config file that made it to a public repository undetected. Unmanaged, overly permissive machine identity access privileges can lead to costly breaches or, in the best-case scenario, a public embarrassment to your brand.

What can you do?

Enforce short credential lifetimes and implement Just-in-Time (JIT) and Just-Enough Privileges (JEP) principles in your machine identity management policies. 

• Just-Enough Privileges: Permissions are granularly scoped to a specific action or resource. 
• Just-in-Time Access: Access is granted dynamically based on operational needs for a limited and pre-set time window, after which access is automatically revoked.

Following these principles ensures that NHIs and machine identities get just the minimum permissions required to perform an action, only for the duration of time they need them. These practices also align with zero trust principles by eliminating implicit trust and limiting access to a time window and specific context.

In complex environments where machine identities are created programmatically (like with CI/CD functions or serverless architectures), JIT and JEP are essential for scaling securely. Keep in mind that only automation can enforce JIT at the cloud scale without slowing your teams down. Manual permission scoping doesn’t scale—automation ensures every identity gets only the access it needs, only when it’s needed.

2. You Can’t Protect What You Can’t See: Automate Machine Identity Discovery and Inventory

Machine identities often sprawl in the background, provisioned by infrastructure as code tools, spun up by scripts, or created for testing and never cleaned up. Without a comprehensive, up-to-date catalog of all machine identities, it’s impossible to consistently apply access policies, monitor behavior, enforce compliance, and stay secure. 

Unmanaged shadow identities create dangerous gaps in your security posture and serve as stealthy entry points for attackers, as they typically carry excessive permissions and stay active long past their intended use. 

What can you do?

Automate the discovery and classification of machine identities across your stack. Use tools that can scan your cloud environments and IAM databases to identify credentials (like secrets, tokens, certificates) and then attribute them to actual machine identities. After all, you can’t protect what you can’t see—automated discovery reveals hidden machine identities and keeps your inventory current in real time. 

This second step—identity attribution—is just as critical. Credentials alone don’t tell you which service, application, or workload created or owns them, especially in dynamic environments using infrastructure-as-code or ephemeral services. Mapping each credential to an owning system, usage context, and lifecycle stage ensures you’re not just building a list of secrets but constructing a complete machine identity inventory.

With full, real-time visibility into both credentials and their associated identities, you can detect orphaned or unused credentials, flag over-privileged non-human identities, track machine identities throughout their lifecycle, and enforce consistent policies.

3. Beyond Discovery: Monitor and Audit Machine Identity Activity

Machine identities don’t behave like human users. They don’t log in at predictable times or exhibit human-like workflows, making traditional anomaly detection methods ineffective. Instead, organizations must develop behavioral baselines for each machine identity, tracking expected usage patterns over time.

Without continuous monitoring and analysis, you risk missing privilege escalations or signs of credential compromise. This point of vulnerability weakens your security posture and complicates compliance with standards like SOC 2, GDPR, PCI DSS, ISO 27001, and HIPAA.

What can you do?

Implement continuous logging and behavioral monitoring for all machine identities. Track when, where, and how they’re used with audit logs that capture access requests, permissions granted, and resources accessed. Automation turns raw logs into real-time insights, detecting risky behavior before it becomes a breach.

Advanced security solutions can flag deviations from normal behavior, such as a CI/CD service account accessing a production database it’s never touched before. These anomalies often precede or indicate credential compromise, privilege escalation, or lateral movement. By combining audit trails with AI-driven threat detection and behavioral analytics, your security team can proactively detect and respond to threats before they become breaches. 

4. Un-silo Your MIM: Centralize Access Control

In most organizations, access to cloud platforms, SaaS software, databases, CI/CD tools, and internal services is managed in silos. This fragmented approach makes it nearly impossible to maintain visibility and enforce consistent policies, not to mention the challenge of detecting privilege inconsistencies across environments.

In reality, this means that teams rely on manual processes or ad-hoc permissions that are difficult to audit and easy to abuse. Over time, this leads to inconsistent enforcement of security policies across identities and an increased risk of misconfiguration and unauthorized access.

What can you do?

Adopt a centralized access management strategy that brings all human and machine identity permissions under a unified framework. This allows you to apply least privilege policies consistently and reduce manual overhead. Automated policy enforcement removes guesswork and human error, ensuring consistent controls across every environment.

The best cloud-native access management platforms offer a single control layer over permissions across cloud and on-prem environments, allowing teams to manage access flows without compromising on agility or security.

5. Keep Them Spinning: Automate Credential Rotation

Machine identities that rely on static credentials that don’t change or expire are vulnerabilities waiting to be exploited. This is especially true if the NHI is not logged or monitored. These stale credentials can be low-hanging fruit for threat actors. Worse, a single leak can compromise numerous components or systems in your stack if the same credentials are reused across systems or embedded in public-facing code.

What can you do?

Automate the expiration and rotation of all machine identities’ credentials, with short validity periods for secrets. Static secrets are sitting targets, and manual rotation at scale is unrealistic; only automation can ensure secrets expire on time.

In addition, schedule refreshes on each deployment or use of a machine identity on any system or service. You can employ tooling that integrates with your CI/CD pipeline and secret management solutions to enforce these policies at scale.

Machine Identity Management Use Cases in Action

The best practices we discussed offer a strong foundation, but what do they look like in real-world environments? Below, we walk through two scenarios where a robust MIM strategy leveraging a cloud-native access management platform resolves the challenges.

Protecting CI/CD Pipelines, Workloads, and Automated Deployments

Let’s imagine a scenario in action: CI/CD pipelines are highly dynamic and automated environments. New resources and identities are spun up on the fly, with little to no InfoSec oversight. Machine identities for build agents, deployment scripts, and container orchestrators often require access to resources, but too frequently, they’re granted privileged and static credentials.

How Apono helps:

Apono brings JIT and JEP automation for machine identities in your development workflows and CI/CD pipelines. Fully integrated with your CI/CD stack, the platform ensures that every non-human identity gets only the minimum access required, only when needed, and for a limited time. Forget about manual provisioning, and stop relying on static code scanners to catch code secrets hiding in public code or configuration files.

Contextual Application Access to Cloud Resources

Here’s another scenario. Applications in microservices or cloud-native architectures routinely access services and resources (like databases and APIs), programmatically creating and using machine identities authenticated using tokens, certificates, or service account passwords. If all these credentials are not managed adequately, they become a cloud security risk. Moreover, without adequate oversight or ownership of machine identities in your systems, it becomes impossible to track access, enforce policies, or meet compliance requirements.

How Apono helps:

Apono centralizes and automates access control management and MIM policy enforcement for applications and their machine identities. Auto-expiring, granular permissions, comprehensive audit logs, and automated workflows reduce the operational risks presented by unmanaged machine identities. Cloud-native teams can finally enforce granular access policies for machine identities, without slowing down deployments or burdening DevOps with manual IAM tasks.

Why is automation essential for machine identity management?

These use cases above highlight how automation bridges the gap between security and scale, ensuring machine identities are governed without slowing innovation.

You can’t manually manage machine identities in cloud-native, API-driven, codified environments. No human can. The speed at which non-human identities are spun up programmatically demands capabilities that traditional identity governance tools do not have. Reliance on manual processes is a recipe for privilege sprawl and shadow NIHs. Plus, very exhausted InfoSec teams.

Since automation of machine identity generation is what created many of the challenges in MIM, it is essential to close these gaps. Automating dynamic policy enforcement, credential rotation, and consistent machine identity lifecycles ensures your identities are secure without slowing down DevOps workflows or overwhelming your InfoSec teams. 

Apono is a cloud-native access management platform purpose-built to automate the full lifecycle of machine identity access. It enforces JIT and JEP by default, eliminates standing privileges with auto-expiring permissions, and provides centralized visibility through rich audit logs. Secure your machine identities without slowing innovation with fast, compliant, and secure access across your stack.
See how Apono automates machine identity management at scale—request a demo today.

New VPs of R&D and Customer Experience Join to Drive Platform Expansion and Meet Growing Demand for Intelligent Cloud Access Control

NEW YORK, June 25, 2025 — Apono, the leader in privileged access for the cloud, today announced significant advancements in its leadership team with the appointment of Tamir Verthim as Vice President of Customer Experience and Arik Kfir as Vice President of Research and Development. Apono’s strategic new leadership appointments underscore its commitment to customer empowerment and platform innovation, further solidifying its industry leadership by proactively addressing the evolving needs of its customer base and meeting the growing demand for intelligent cloud access control.

“At Apono, our customers are at the heart of everything we do, and I’m thrilled to lead the charge in elevating their journey,” said Tamir Verthim, Vice President of Customer Experience, Apono. “My focus will be on building an even more proactive and supportive environment, ensuring every interaction reinforces the value and reliability of our platform. We’re dedicated to transforming customer feedback into actionable insights, driving continuous improvement, and fostering long-term partnerships built on trust and mutual success.”

Tamir Verthim brings over a decade of experience nurturing customer relationships and scaling operational efficiencies to Apono’s leadership team. His extensive background includes impactful roles as Head of Global Sales Engineering at WhiteSource, where he was instrumental in developing scalable operating procedures and standardizing best practices for customer engagement and conversion. Verthim’s prior experience in sales engineering and customer-facing R&D roles at companies like CyberMDX, SAPIENS, and Hewlett Packard Enterprise uniquely positions him to bridge technical excellence with superior customer service. His leadership will ensure Apono’s customer experience remains best-in-class, anticipating needs and exceeding expectations.

“Leading Apono’s R&D efforts, my mission is to accelerate our innovation pipeline, ensuring our cloud access management platform remains at the forefront of security technology and directly addresses our customers’ complex challenges,” stated Arik Kfir, Vice President of Research and Development, Apono. “We are committed to a roadmap that delivers continuous value, empowering our users with highly flexible, secure, and intuitive solutions that adapt to their dynamic environments, today and well into the future.”

Arik Kfir joins Apono as Vice President of Research and Development, a critical role he began in January 2025. With a distinguished career spanning leadership positions at Zesty, Qubex, Zscaler, Trustdome, Unbotify & Infolinks Kfir is renowned for his ability to inject modern R&D methodologies and processes to boost product quality and delivery. He possesses deep expertise in building breakthrough products, scaling engineering teams across multiple locations, and leading significant platform transformations, including shifts to cloud-native architectures. Arik will be instrumental in elevating Apono’s R&D, implementing robust processes for team coordination, planning, and continuous integration and delivery to expand their market-leading cloud access management platform.

Validating Apono’s customer-centric approach and the proven impact of its innovative cloud access platform, Cybereason, a leading global cybersecurity company, has experienced firsthand the transformative benefits of intelligent access management.

“We have been working with Apono for two years now, and their just-in-time approach to access management has transformed how we secure our customer environments,” said Shani Kahlon, Deputy CISO, Cybereason. “Apono allows us to grant granular, time-limited permissions, drastically limiting potential damage if a user is compromised. The flexibility to tailor every access flow based on department, job description, or geolocation is simply amazing. Managing access across multiple cloud vendors from a single platform is a major advantage and truly streamlines our work. My absolute favorite thing about Apono is the team itself—they are incredibly responsive and quick to implement new features or design requests.”

“It’s truly inspiring to see Tamir and Arik’s impact within Apono. Their leadership in customer experience and R&D has been crucial to our success, enabling us to both advance our platform capabilities and maintain a deep understanding of what our customers truly need,” said Ofir Stein, Chief Technology Officer and co-founder, Apono. Their contributions are vital to our mission of enabling enterprises through intelligent cloud access control. I’m incredibly proud of the value they bring to our company and our customers.

Apono’s strategic leadership is set to accelerate the company’s mission to deliver robust and intuitive cloud access management. Their combined expertise will drive unparalleled enhancements in user experience and technological innovation, ensuring Apono remains a vital partner in clients’ security journeys.

About Apono:
Founded in 2022 by Rom Carmel (CEO) and Ofir Stein (CTO), Apono leadership leverages over 20 years of combined expertise in Cybersecurity and DevOps Infrastructure. Apono’s Cloud Privileged Access Platform offers companies Just-In-Time and Just-Enough privilege access, empowering organizations to seamlessly operate in the cloud by bridging the operational security gap in access management. Today, Apono’s platform serves dozens of customers across the US, including Fortune 500 companies, and has been recognized in Gartner’s Magic Quadrant for Privileged Access Management.

As the software world shifted toward microservices and distributed architectures, the volume and complexity of API traffic have skyrocketed. Unfortunately, so has the number of API-related breaches and cyber attacks.

Last year, nearly 44% of all advanced bot traffic online targeted API endpoints, while traditional web applications received just 10% of the malicious traffic. It’s no surprise that 57% of organizations admit to having suffered API-related breaches in the past two years.

Your API gateway serves as the primary public-facing interface to your digital services. As such, its functionality and protection are often critical for business operations and your organization’s overall resilience against cyberattacks. Understanding how API gateways work (and where they fall short) is key to defending against API-related breaches.

How API Gateways Work

An API gateway acts as a front door to your API ecosystem. It sits between clients and backend services, centralizing the execution of common tasks to simplify architecture and enhance scalability. Key capabilities of an API gateway include:

• Request routing – Directs incoming API calls to the appropriate backend service based on predefined policies and rules.
• Protocol translation – Converts requests between different formats (like HTTP to WebSocket or REST to gRPC) to enable smoother interoperability.
• Rate limiting and throttling – Manages incoming API traffic to protect backend services from overload or abuse.
• Caching – Serves frequently requested data to reduce backend load and improve response times.
• Authentication and authorization – Performs initial identity verification and enforces high-level access control policies.

How does an API gateway improve security?

From an InfoSec perspective, an API gateway is the first line of defense against API-based threats. It can reject malformed or unauthorized requests before they reach internal systems, acting as a centralized API firewall that helps stop common attack vectors (like injection attacks, credential stuffing, and brute-force entry attempts) by enforcing strict schema validation and access policies.

Ideally, an API gateway reduces your attack surface by enforcing a consistent set of security policies, ensuring that only properly formatted, authenticated, and authorized requests are forwarded to backend services.

That said, API gateways have inherent limitations. Most lack the fine-grained, identity-aware access controls needed to manage non-human identities (NHIs) like service accounts, API keys, and tokens. Gartner estimates machine identities outnumber human identities by 45x. These machine identities often have broad, persistent access privileges, making them attractive targets in API abuse scenarios.

As your software architecture becomes more complex and your organization scales, this design limitation can evolve into a serious security gap. In fact, several organizations have already experienced high-impact breaches as a result.

Real-World Consequences of API Gateway Limitations

While API gateways are critical for managing traffic and providing initial authentication, their inherent limitations, especially around unmanaged and risky non-human identities (NHIs) with excessive access permissions, make them a primary vector for attacks.

The following real-world breaches from recent years illustrate just how dangerous these vulnerabilities can be.

1. Trello: API Enumeration Exposed 15 Million Users

In January 2024, researchers found that Trello’s public API could be exploited to enumerate user accounts. Attackers scraped roughly 15 million profiles, including usernames, email addresses, and other personal identifiable information (PII), which they then offered for sale on the Dark Web. Although there was no system intrusion, attackers achieved data scraping of publicly available API endpoints. 

2. Microsoft OAuth Application Compromise

The threat group APT29 compromised a non-production tenant account and then exploited a test OAuth application, which acted as an overprivileged non-human identity. This activity led to unauthorized access to Microsoft employee email accounts and demonstrated how NHIs can be leveraged for lateral movement, as documented in Microsoft’s blog.

3. Spoutible: Insecure API Exposed User Data and Credentials

Also, in early 2024, the social platform Spoutible suffered a breach due to multiple critical API vulnerabilities. These included broken authentication, inadequate token validation, and exposed endpoints. These flaws allowed attackers to access sensitive user data (including hashed passwords), highlighting serious gaps in data privacy and the lack of effective security controls to protect user information.

4. Internet Archive Zendesk Token Exposure

Attackers exploited unrotated API keys and Zendesk tokens, which are static non-human credentials, to gain access to approximately 800,000 support tickets from the Internet Archive. This incident underscored the critical importance of managing and securing NHIs, particularly in customer support systems.

Source

5. T-Mobile: API Misuse Exposed SIM Data and User Metadata

In a headline-making breach in 2023, T-Mobile exposed the personal data of approximately 37 million customers due to a misconfigured API with overly permissive access to sensitive customer data. The data leaked included phone numbers, account metadata, and SIM card information that put users’ privacy at risk.

How API Gateways Fall Short in Authentication and Authorization (and How Access Management Platforms Can Help)

All these incidents expose a recurring pattern: static credentials and over-privileged service accounts. OAuth 2.0 client credential abuse is one of the most common non-human identity (NHI) abuse vectors, exploiting often long-lived and overly permissive access tokens.

In every case, the API gateway did its job (routing traffic and enforcing basic policies). Still, it failed to prevent the breach or leak as it lacked the identity-aware security layer with the granularity and dynamic nature required to effectively protect modern APIs in cloud environments.

1. Lack of Granular Authorization

Most API gateways rely on binary access control: a user is either allowed or denied access based on high-level roles or tokens. They lack the ability to enforce “just enough” or context-specific permissions. This challenge highlights the need for a robust cloud-native access management platform like Apono. For example, Apono bridges this gap by enabling fine-grained authorization down to the API endpoint or database field level, ensuring users and services can access only what they truly need.

2. Unlimited API Key Lifetime

API gateways typically don’t support time-limited, conditional access for NHIs, meaning an API key, once issued, remains valid until manually revoked, regardless of context. If an API key is valid, it works, no matter when, how, or by whom. 

Apono’s just-enough and JIT (just-in-time) access models grants temporary, on-demand permissions, which expire automatically. Enforcing just-enough access with a platform like Apono drastically reduces the risk of credential misuse if a key or service token is compromised.

3. Standing Privileges

Standing privileges are one of the most dangerous blind spots in API security. Gateways don’t track or limit persistent access by NHIs. Yet, an automated access management platform eliminates this risk by automatically revoking access once it’s no longer needed, shrinking the attack window for compromised access credentials.

4. Manual Access Management Configuration

Gateways often require manual configuration changes or ticket-based workflows to grant API access, slowing down engineering teams and increasing the risk of configuration drift. That’s why selecting a platform that integrates with tools like Slack, Teams, and the CLI is important, granting developers self-serve access to make requests safely and quickly without compromising on security or compliance.

Let’s look at an example. When paired with an API gateway, Apono brings the identity-aware, context-driven security that today’s API-driven environments demand and can close the gaps that API gateways alone simply aren’t designed to address.

Table 1: API Gateway Security Risks and Solutions

API Gateway Security Risk	Solution (Using Access Management Platform)
Lack of granular authorization	Enable fine-grained authorization down to the API endpoint or database field level.
Unlimited API key lifetime	Enforce just-enough access to drastically reduce the risk of credential misuse if a key or service token is compromised.
Standing privileges	Automatically revoke access once it’s no longer needed, shrinking the attack window for compromised access credentials.
Manual access management configuration	Integrate the platform with tools like Slack, Teams, and the CLI, granting developers self-serve access to make requests safely and quickly.

7 API Gateway Security Best Practices for InfoSec

When appropriately configured with the right stack and aligned with cybersecurity standards, API gateways can safeguard your systems from attackers and prevent unintended data leaks.

1. Centralize and Harden Authentication

To ensure a unified identity layer and avoid inconsistencies across services, use centralized authentication with standards like OAuth 2.0 or mutual TLS (mTLS). This best practice simplifies policy enforcement and reduces your attack surface. Configure your gateway to automatically reject requests without valid tokens (that are both signed and cryptographically validated).

2. Implement Granular and Contextual Authorization

While authentication confirms identity, authorization controls what that identity can do. Broad access controls often lead to excessive permissions. Apply role- and attribute-based access controls (RBAC/ABAC) at the API level. Integrate policy engines like OPA (Open Policy Agent), projects like Cedar (AWS), or gateway-native plugins to enforce least privilege consistently. This strategy helps reduce the blast radius if credentials are compromised, preventing attackers from achieving worst-case-scenario outcomes like remote code execution.

3. Apply Rate Limiting and Throttling to Curb Brute-Force Attacks

API gateways excel at managing traffic. To defend against brute-force tactics like credential stuffing, configure IP-based rate limiting, API key quotas, and per-client thresholds. Tailor these limits to each endpoint’s risk profile. Login and registration routes, for example, should have stricter controls and visibility.

4. Segment Protection of Internal and Public APIs

Treat public and internal APIs differently. Route internal traffic through a dedicated ingress path, reinforced by stricter firewall rules and identity lifecycle management policies. API gateways should support internal vs external routes with different ingress controllers or namespaces. Use gateway tags, virtual services, or separate gateways to enforce segmentation. Without clear separation, attackers can pivot laterally once inside the perimeter.

5. Enable Deep Logging and Real-Time Monitoring

Log every request, status code, authentication result, and header. These logs should integrate with your observability tools to help detect anomalies like spikes in 401/403 responses, sudden usage shifts, or repeated failures. Implement alerting rules to transform this data into real-time incident detection that your SOC team can act on.

6. Sanitize and Validate Inputs at the Gateway

APIs are prime targets for injection attacks and schema abuse. Block malformed or malicious requests by enforcing JSON schemas, rejecting oversized payloads, validating query parameters, and performing JSON Web Token (JWT) validation. Many gateways support native request validation or allow you to layer WAF or custom middleware logic at the ingress point.

7. Maintain and Update APIs and Gateway Configurations

Unmaintained endpoints and hard-coded credentials are the leading causes of API-related breaches. Codify your gateway configurations and integrate them into your CI/CD pipeline. It supports versioning, deprecation enforcement, and secrets management. Maintain an updated API catalog and monitor for exposed or unauthorized endpoints in production.

Bridging the Authorization Gap with Apono

API gateways are essential for managing traffic, enforcing perimeter-level policies, and providing a first line of defense against API abuse. But as we’ve seen, their built-in capabilities fall short when it comes to fine-grained access control—especially for NHIs, which are prime targets for attackers. As we saw in the examples above, Apono helps to seal the gap in your API gateway security.

While your API gateway handles traffic routing, rate limiting, and basic authentication processes, Apono enforces the granular, context-aware access controls that define who (or what) those APIS can actually do. Automated Just-enough access helps to eliminate elevated standing privileges across your stack including machines without slowing down development.

Combined with comprehensive audit logs and automated reporting, Apono provides full visibility into every permission: who has it, how they got it, and why.Are you ready to close the gap in your API security strategy? Book a demo to see Apono in action.

Often overlooked, identities are prime targets for bad actors. In December 2024, a compromised API key in the BeyondTrust Remote Support SaaS environment was enough to cause a privilege escalation attack. The year before, Microsoft hit the headlines as an SAS token leak exposed over 38TB of sensitive data. 

The good news is that simplifying user access and eliminating security risks from standing privileges has never been more achievable thanks to the right identity lifecycle management (ILM) tools. 

With the rapid growth of non-human identities (NHIs), such as service accounts and APIs, the importance of smart automation in identity management is soaring. As a result, 78% of organizations are gearing up to boost their Identity and Access Management (IAM) spending in 2025, including on ILM tools. 

10 Best Identity Lifecycle Management Tools at a Glance

• Best overall for Cloud privilege access management: Apono
• Easiest integration with the Microsoft ecosystem: Microsoft Entra ID 
• Best for comprehensive enterprise identity governance: SailPoint IdentityIQ
• Best for SaaS integrations: Okta
• Best for converged identity & privileged access security: CyberArk Identity
• Best for SMBs: JumpCloud Identity Lifecycle Management
• Best for large enterprises & complex hybrid environments: Ping Identity
• Best for user-friendly SSO: OneLogin
• Best for developers building custom app authentication: Auth0 (by Okta)
• Best for Oracle-centric enterprises: Oracle IAM

What are identity lifecycle management tools?

Identity lifecycle management refers to the entire process of managing a user’s digital identity and their associated access privileges from the moment an identity is created until it is deprovisioned. 

Identity lifecycle management tools are software solutions designed to automate and streamline complex processes. They are crucial for handling tasks such as automated provisioning and deprovisioning for both human and non-human identities (NHIs) and just-in-time (JIT) access, as well as implementing robust role and policy-based access control (RBAC and PBAC). 

Automating these functions significantly reduces manual effort and enhances your organization’s overall security posture. ILM tools provide a centralized platform for:

• Managing user accounts: This encompasses the creation, modification, and deletion of user accounts across various systems and applications. For example, handling changes in employee status.
• Assigning permissions: Identity lifecycle management tools enable the precise assignment of access rights and privileges to users based on their roles, responsibilities, and specific business needs. 
• Enforcing policies: These tools are instrumental in enforcing organizational security policies and compliance mandates in line with requirements like GDPR and SOC 2. 
• Maintaining an audit trail for compliance: Meticulously recording all identity-related activities and access events. 

Types of Identity Lifecycle Management Tools

While many identity lifecycle management (ILM) solutions offer a broad range of capabilities, understanding these distinctions can help you identify the right one for your needs.

• Identity Governance and Administration: Focuses on governance by managing digital identities and access rights, enforcing policies, conducting access certifications, and ensuring compliance. Provides visibility into who has access to what.
• Access Management: Deals with how users (human and non-human) authenticate and authorize access. Includes SSO, MFA, API security, and adaptive access policies, ensuring only authenticated and authorized users reach resources.
• Privileged Access Management: Secures and manages highly sensitive accounts and credentials (e.g., administrators and service accounts). Controls, monitors, and audits privileged access to critical systems, often with session recording and just-In-time (JIT) access. 

Benefits of Identity Lifecycle Management Tools 

• Enhanced security: ILM tools are your secret weapon for enforcing least privilege, ensuring every single identity (human or non-human) gets precisely the minimal access it needs. 
• Improved operational efficiency: Automating identity processes cuts manual overhead, freeing up teams for strategic work.
• Simplified compliance & auditing: ILM tools offer clear visibility into access for regulatory compliance and easier audits.
• Better user experience: Self-service portals in ILM tools mean quicker access requests and smoother onboarding for human users.
• Reduced human error: Automating identity lifecycles minimizes manual mistakes that can create vulnerabilities or access issues.

What key features should you look for in an identity lifecycle management tool?

Unified Identity Management 

Several key features are essential for robust security and efficient operations when selecting an identity lifecycle management tool. First, the tool should seamlessly integrate with all major cloud platforms, your preferred DevOps tools, and CI/CD pipelines for a unified approach to identity management. 

JIT Access

Second, the ability to enable just-in-time (JIT) access is vital. This dynamic approach grants precisely scoped, temporary permissions that automatically disappear when no longer needed. JIT access eliminates risky standing privileges, preventing prolonged exploitation, as seen in incidents like the Internet Archive Zendesk Token Exposure in 2024, which involved unrotated API keys.

Automated Provisioning & Deprovisioning

Look for automated provisioning and deprovisioning capabilities that streamline efficient onboarding, role changes, and offboarding. This feature is crucial given that compromised non-human identities are increasingly leveraged in real-world attacks. For instance, the Okta Support System Breach in October 2023 involved a compromised service account that lacked sufficient monitoring, allowing attackers to steal customer credentials.

Security for NHIs

Robust non-human identity (NHI) support is a must. The best tools specifically manage the unique lifecycle and security needs of NHIs, such as service accounts and API keys, with the same rigor applied to human users. 

Granular Access Control 

Self-serve, granular access control allows for fine-grained control over permissions, dynamically leveraging attributes and context, like time or location, to create highly specific access policies.

10 Top Identity Lifecycle Management Tools 

1. Apono

Apono is a cloud-native access management platform that modernizes identity lifecycle management by automating just-in-time (JIT) and least privilege access. Apono manages access dynamically, granting precisely scoped, temporary privileges for identity’s that are automatically revoked. It ensures all identities (both humans and non-humans) have the right access to do just what is needed, helping bring zero trust to all your identities. With Apono you can:

• Streamline onboarding and offboarding for all identities and provides detailed audit logs to enhance lifecycle visibility.
• Enable on-demand, self-serve, granular permissions directly from Slack, Teams, or your CLI and integrates with various cloud providers.
• automatically suggest dynamic policies that fit your business needs, streamlining cloud access lifecycle and gaining control of cloud privileged access.

Best overall for Cloud privilege access management.

Price: By inquiry. 

Review: “As head of IT, It gives me peace of mind when I know that only the right users get proper access to the system’s DB at the right time; with Apono I don’t need to worry about managing DB privileges since Apono makes sure that the key is automatically revoked upon  completion.”

2. Microsoft Entra ID (formerly Azure Active Directory)

Microsoft Entra ID, formerly Azure Active Directory, is Microsoft’s cloud-based IAM solution. It is a central hub for managing user identities and controlling access to applications and resources, both within the Microsoft ecosystem and for third-party services. Its features include single sign-on (SSO), multi-factor authentication (MFA), and lifecycle workflows for human users. 

Price: Offers a free tier and various paid editions (e.g., Premium P1, Premium P2) with per-user pricing.

Best for: Easiest integration with the Microsoft ecosystem.

Review: “It offers seamless integration with Microsoft 365 and Azure services, strong identity protection, SSO, and conditional access policies.”

3. Ping Identity

Ping Identity provides an enterprise-grade identity platform for securing customer and workforce access. It offers a range of authentication, authorization, and identity governance solutions, API security capabilities, and flexible deployment options (cloud, on-premises, hybrid).

Price: By inquiry.

Best for: Large enterprises & complex hybrid environments.

Review: “Ping Identity is super easy to use and configure; their support team has helped us with any issues we’ve had during setup.”

4. OneLogin

OneLogin, now part of One Identity, is a cloud-based platform offering secure single sign-on (SSO), multi-factor authentication (MFA), and lifecycle automation. It simplifies access control by centralizing identity management in a single directory, helping organizations sync user data across applications and enforce consistent security policies.

Price: By inquiry; tiered pricing based on features and user count.

Best for: User-friendly SSO.

Review: “Remembering one passphrase that gives me access to all my corporate applications is as simple as it can get.”

5. Auth0

Auth0 is an identity platform designed to support developer productivity by simplifying the implementation of authentication and authorization within custom applications. It provides tools for building secure identity services in web, mobile, IoT, and backend applications.

Price: Offers a free developer plan, then tiered pricing based on active users and features.

Best for: Developers building custom app authentication.

Review: “What I really like about Auth0 is its flexibility in authentication flows. I can easily set up social login and multi-factor authentication.”

6. SailPoint IdentityIQ

SailPoint IdentityIQ is a comprehensive identity governance and administration (IGA) solution that helps large organizations manage digital identities and access rights. It offers automated provisioning and deprovisioning to streamline identity lifecycle management, plus robust reporting capabilities. 

Price: By inquiry.

Best for: Comprehensive enterprise identity governance.

Review: “The most helpful feature is its ability to automate access reviews and policy enforcement, which simplifies managing user permissions and ensures everything stays secure.”

7. Okta 

Okta is an identity provider that offers a cloud-based platform for managing and securing workforce and customer identities. It supports SSO, MFA, API access management, and automated user provisioning and deprovisioning across various applications and services.

Price: By inquiry. Pricing varies based on features and user count.

Best for: SaaS integrations.

Review: “What I like best about Okta is that it [provides] one-step sign-in for most of the tools we use.”

8. CyberArk Identity

CyberArk Identity is part of CyberArk’s broader Identity Security Platform. It’s designed to secure access for all types of identities—including workforce users, customers, and particularly privileged users—across various applications and IT environments. CyberArk Identity evaluates real-time context (e.g., location and behavior) to make dynamic access decisions. 

Price: By inquiry.

Best for: Legacy identity & privileged access security.

Review: “The CyberArk Identity tool has various capabilities such as managing privileged accounts [and] providing secure access to resources.”

9. JumpCloud Identity Lifecycle Management

JumpCloud Identity Lifecycle Management is offered as part of a broader cloud directory platform designed to unify identity and device management. It provides a single, cloud-based directory to manage all user identities and automates granting and revoking user access to applications.

Price: Offers a free tier for up to 10 users/devices, then tiered pricing based on features and user count.

Best for: SMBs.

Review: “We use it for everything from enforcing security policies on Macs to managing SSO across dozens of SaaS tools.”

10. Oracle IAM

Part of Oracle’s broader enterprise software suite, Oracle IAM offers identity governance, access management, directory services, and security for both on-premises and cloud environments. Another big tick is that it seamlessly integrates with other Oracle databases and cloud services. 

Price: By inquiry.

Best for: Oracle-centric enterprises.

Review: “Very easy to add groups, user access, and user control.”

Table 1: How the Solutions Stack Up

Solution	Key features	Best for	Price
Apono	Automates JIT access. Enables on-demand self-serve, granular permissions. Streamlines the cloud access lifecycle.	Best overall for cloud-native & DevOps teams	By inquiry
Entra ID	Lifecycle workflows for human users within the MS ecosystem and third-party services.	Integration with the Microsoft ecosystem	Free & paid tiers
Ping Identity	Authentication, authorization & identity governance solutions.	Large enterprises & complex hybrid environments	By inquiry
OneLogin	Centralizes identity management in a single directory.	User-friendly SSO	Tiered pricing
Auth0	Authentication and authorization within custom applications.	Developers building custom app authentication	Free & paid tiers
SailPoint IdentityIQ	Identity governance and administration (IGA), incl. provisioning and deprovisioning.	Comprehensive enterprise identity governance	By inquiry
Okta	SSO, MFA & API access management.	SaaS integrations	By inquiry
CyberArk Identity	Real-time context analysis.	Converged identity & privileged access security	By inquiry
JumpCloud	Automates granting and revoking user access to applications.	SMBs	Free & paid tiers
Oracle IAM	Identity governance, access management & directory services.	Oracle-centric enterprises	By inquiry

Apono: Purpose-Built for Modern Identity Access Challenges

Managing identities, especially non-human ones like service accounts and API keys, has become a real challenge in today’s cloud-native environments. Apono stands out as the top solution for revolutionizing identity management. Apono helps teams define and enforce who can access what, when, and for how long, without slowing down engineering workflows. It’s not just about security anymore; it’s about enabling productivity while staying audit-ready.

Apono empowers secure, efficient operations with configurable break-glass and on-call access flows to remediate production errors faster while providing granular access to required resources. It also deploys in less than 15 minutes, allowing for rapid integration into your existing security stack.

Ready to eliminate standing privileges and automate lifecycle control for every identity? Book a demo with Apono and modernize your identity security strategy.

Security breaches are increasingly expensive and harder to spot, extending beyond common attacks like phishing. Attackers are now targeting the least visible parts of your infrastructure: non-human identities (NHIs). 

NHIs outnumber human identities by 45:1 in cloud environments—these include service accounts, APIs, applications, and bots that interact with systems and access sensitive data. Unlike human users, NHIs don’t trigger typical alerts, allowing silent, prolonged operation with valid credentials. The consequences of a compromised NHI can be severe: attackers can gain unauthorized access to your sensitive data, spin up costly cloud resources, or even create new backdoors that lock you out of your own systems. 

It takes an average of 258 days to identify and contain a data breach—that’s more than eight months of dangerous exposure. Therefore, comprehensive prevention strategies are more time-sensitive and critical than ever for protecting non-human identity risks. 

What are non-human identities?

Non-human identities (NHIs) refer to any entity interacting with your systems that’s not a human user—for example, containers, workloads, and even scripts or schedulers. As environments scale, so does the number of NHIs, often into the thousands. These identities often need access to infrastructure, databases, or third-party services like human users, but they behave very differently. Many NHIs are spun up automatically by tools like Terraform or Kubernetes, making them harder to track and secure.

For example, a CI/CD pipeline that deploys code to production might use a service account to authenticate with your cloud provider. A monitoring tool might also use an API key to access logs and metrics. These identities don’t login through a UI or use passwords like humans do, but they still hold permissions.

However, the problem isn’t that NHIs exist. It’s that they’re easy to forget, hard to monitor, and frequently over-permissioned. Many of them are granted broad, long-lasting access that no one remembers to review until a breach happens, leading to a loss of revenue or data. This inherent lack of oversight and tendency towards excessive access directly conflicts with the core principles of zero trust, which mandates that no identity (human or non-human) should be implicitly trusted. Applying zero trust to NHIs is crucial to mitigate these risks, as we’ll explore later. 

Non-Human vs. Human Identities

A human identity represents a person, like someone logging into a dashboard. In contrast, non-human identities represent systems or services performing automated tasks without human intervention, like an API key or service account.

For example, a developer logging into a system to deploy code is a human identity. At the same time, a microservice in your architecture, fetching data from a database using an API key, is a non-human identity. In this case, no one is “logging in,” but activities are being carried out.

Table 1: Key Differences Between Human and Non-Human Identities

Category	Human identities	Non-human identities
Who or what?	Actual people, such as engineers and development teams.	Systems, services, applications, bots.
Access type	Through a console, Command Line Interface (CLI), or a User Interface (UI)	Programmatic access using scripts, APIs, or automation.
Authentication	Multi-factor authentication, passwords, SSO.	API tokens, keys, service account credentials.
Credential lifespan	Regularly updated or rotated.	Long-lived.
Monitoring	Can be tracked via usernames or audit trails.	Harder to track and often overlooked.

5 Examples of Non-Human Identities

NHIs appear in many forms. Below are five of the most common examples security teams should track.

1. API Keys

API keys are secret tokens that let apps and services talk to each other. Imagine a chatbot pulling data from a customer support system using an API key. If that key is leaked or not rotated regularly, attackers can hijack it and steal data.

2. Cloud Services

Cloud providers like AWS, Azure, and Google Cloud use built-in identities to manage their own services. They often use identity and access management (IAM) roles to interact with your virtual machines and resources (for example, a monitoring service checking the health of a virtual machine). When permissions aren’t carefully controlled, they can expose sensitive parts of your infrastructure.

3. Containers and Images

Containers like Docker package code and dependencies so apps can run consistently across environments. A Docker container running a Node.js app will have to assume an IAM role to fetch secrets from AWS Secrets Manager. 

4. DevOps Tools

DevOps tools rely on non-human identities to build, test, and deploy applications and function securely. These tools often need credentials to access repositories, databases, or cloud resources. They can become risky gateways into your infrastructure without tight control and audit. For example, Terraform won’t just automatically create resources in your AWS account—it needs an AWS IAM role or authorization.

5. Service Accounts

A service account is an identity that applications or services use to interact with other systems. For example, a backup tool might use a service account to copy files from a server to cloud storage. The service account runs quietly in the background, but it can become a serious risk if it has too much access or gets exposed.

4 Security Risks of Non-Human Identities You Can’t Ignore – Plus Security Strategies to Mitigate Them

Security teams must understand where these identities exist, their privilege levels, what they’re allowed to do, and how to manage them effectively. Here are five security risks of non-human identities and how to handle them.

1. Excessive Permissions

Many non-human identities have more access controls than they actually need. A service account meant to read data might also be able to write or delete it simply because no one took the time to restrict its permissions. This over-permissioning increases the chances of a breach and accidental mistakes. 

To stay secure, follow the principle of least privilege: give each identity the smallest set of permissions it needs and nothing more. Review these permissions regularly and remove anything unnecessary.

2. Lack of Visibility and Governance

It’s common for organizations to lose track of the non-human identities they create. Developers spin up test credentials or containers and forget about them. Without a central view of who owns what, orphaned identities pile up and become invisible doors into your system. These forgotten, untracked accounts are often referred to as “shadow NHIs,” and they present a growing blind spot in security posture assessments.

When a breach happens, detecting where the leak came from becomes difficult. To reduce the risk, build a clear inventory of all NHIs, tag each with an owner, and set expiration dates or alerts for inactivity.

3. Insecure Credential Management

Where and how do you store your credentials? Do you hardcode them? Share them in Slack or let them sit in plain text config files? If one of these leaks, it can act like a master key for attackers. This kind of exposure is one of the fastest paths to a data breach. 

If you use AWS cloud services, a better approach is to manage secrets using secure tools like AWS Secrets Manager. Avoid hardcoded credentials, use environment variables, shut down inactive accounts, and rotate static credentials regularly to limit the damage if one gets exposed.

4. Lateral Movement Potential

When attackers gain access to one NHI, they often try to move sideways within your system. For example, if they take over a compromised container, they might use its permissions to reach your storage buckets, databases, or other services. This kind of lateral movement turns a small breach into a much bigger one. 

To reduce this risk, isolate non-human identities wherever possible. Use network segmentation, enforce zero-trust principles, and monitor their behavior for unusual activity that could signal a problem.

What Happens When NHIs are Attacked

When an NHI is compromised, the bad actor can move through your systems unnoticed. Unlike human users, NHIs don’t trigger login alerts or password reset workflows. They are fully integrated into your automation, which means an attacker can silently operate with valid credentials, often for weeks or months, before anyone notices.

The consequences? They gain unauthorized access to your data, spin up costly cloud resources, or even create new backdoors, and even worse, lock you out of your own system. 

These risks aren’t a fantasy scenario—they are happening now, in the real world. 

For example, in December 2024, an overprivileged API key was compromised in the BeyondTrust Remote Support SaaS environment. This static, unmanaged non-human identity allowed attackers to reset local application passwords and escalate privileges, demonstrating how unmanaged NHIs can be misused.

Just a few months earlier, in September 2023, Microsoft AI researchers inadvertently exposed a Shared Access Signature (SAS) token, functioning as a non-human identity, which granted full access to an Azure Storage account. This attack led to a massive leak of over 38TB of sensitive data.

Also, in late 2023, a compromised service account breached the Okta support system. This non-human identity lacked sufficient monitoring, allowing attackers to steal customer artifacts containing credentials, prompting one customer to rotate 5,000 exposed credentials. That’s why early detection and controlled, time-bound access are essential. When NHIs are attacked, the damage is always costly.

How to Stay Secure Against Non-Human Identity Risks

The principle of least privilege (PoLP) is a foundational tenet of robust cybersecurity, especially for non-human identities (NHIs). Least privilege asserts that any user, program, or process should be granted only the minimum necessary access to perform its legitimate function—and no more. Just-in-time (JIT) access is the practice of granting permissions only when needed, and revoking them immediately after, reducing the attack surface from standing privileges.  JIT access is a fundamental means to achieving the principle of least privilege.

Implementing just-enough access ensures an NHI only has precisely the permissions required for its task, which keeps the blast radius, data security risks, and possibility for lateral movement to a minimum. By continually right-sizing permissions, you combat the accumulation of redundant or over-privileged access that often leads to shadow access. This approach reinforces a zero trust security model, where no identity, human or non-human, is implicitly trusted, and every access request is validated against strict, minimal permissions.

A platform like Apono proves invaluable for enforcing the principles of least privilege and zero trust for all your identities. Apono provides a modern, automated approach to access management that helps enforce just-enough access by allowing you to:

• Suggest automated, right-sized access flows across your entire stack to minimize privileged access without hurting productivity.
• Enforce the principles of least privilege and zero trust, minimizing the risks associated with excessive permissions.
• Enable on-demand, self-serve, granular permissions directly from Slack, Teams, or your CLI. Apono ensures that NHIs (and human users) get exactly what they need when they need it, simplifying the path to least privilege adoption.

Automate Just-in-Time Access and Give NHIs Just-Enough Permissions with Apono

Non-human identities are essential, but they also introduce serious security risks when left unmanaged. From excessive permissions to poor credential hygiene, NHIs can quietly expose your systems to breaches.

Apono helps you take back control. As a cloud-native access management platform, Apono enforces least privilege and zero trust by automating just-in-time access, granting permissions only when needed, and revoking them right after. This approach minimizes standing privileges and reduces your attack surface. With features like auto-expiring access, one-click break glass flows, and quick deployment, Apono simplifies secure access across your stack. Book here to see a demo.

With this release, Apono provides customers a unified cloud access solution that delivers automated, Just-in-Time, Just Enough access for every identity—whether person or machine

NEW YORK, May 28, 2025 — Apono, the leader in privileged access for the cloud, today announced a significant update to the Apono Cloud Access Management Platform, introducing new capabilities for managing and securing Non-Human Identities (NHIs). This expansion provides organizations with essential tools to discover, manage, assess, and quarantine NHIs, enabling a move towards a just-enough least privilege access model across their cloud ecosystem. Building off the platform’s existing capabilities, this update delivers a unified cloud access solution that delivers automated, Just-in-Time, Just Enough access for every identity, whether person or machine.

“The widespread growth of over-privileged non-human identities in the cloud presents a critical security challenge – they are prime targets for attackers and introduce substantial risk and blind spots into vital cloud infrastructure,” said Ofir Stein, CTO at Apono. “Our latest platform update is specifically designed to combat this by giving organizations the essential tools to discover, manage, assess, and even quarantine identities. This enables a crucial shift to a just-enough, least privilege model for non-human access at scale.” 

The scale and complexity that cloud infrastructures have enabled have been crucial catalysts for innovations today. NHIs have served as vital tools in enabling automation within these complex environments. Scaling alongside cloud adoption led to an explosion in the number of NHIs, with NHIs often vastly outnumbering human users. While these NHIs are fundamental to powering modern cloud-native applications and services, their widespread presence and often-overlooked privileges create significant blind spots and introduce substantial risk.  

The new capabilities in the Apono platform are designed to eliminate these blind spots and provide a unified approach to identity and access management across human and non-human entities. This innovation allows organizations to eliminate standing privilege effectively, achieve just enough privilege for NHIs, and enforce end-to-end least privilege, a critical component of a zero-trust architecture, while maintaining development velocity and operational efficiency. 

Key capabilities of the Apono platform update include: 

• Discovery and Observability: The platform can identify various types of NHIs, such as service accounts, secrets, API keys, IAM roles, IAM users, and Permission sets.   
• Risk Assessment and Recommendation: It can determine the risk associated with discovered NHIs and recommend actions to mitigate those risks.   
• Just Enough Access and Least Privilege Migration: The update reduces permission levels on NHIs, automates Just-Enough Access provisioning, and enables migration to a least-privilege access model. 
• Dormant and Zombie NHI Identification and Quarantine: The platform can identify unused or abandoned Identities that pose a high risk due to their access levels and safely quarantine them by removing assigned access. 

“The rise of NHI usage in the past two years has reaffirmed the need for organizations to firstly discover and understand their NHI posture, but more importantly, move towards a strategic path of risk analysis and remediation,” said Simon Moffatt, Founder & Research Analyst, The Cyber Hut. “NHI management requires more than just credential rotation, and should leverage the same concepts developed over the past three decades in the human-identity space: namely, strong governance, least privilege access, and linkage to business processes. Apono’s investment in this area is testament to significant growth in market demand for these use cases.”

This update significantly enhances Apono’s ability to offer end-to-end coverage for all identities, providing just-in-time and just-enough access without negatively impacting business operations. Unlike many existing solutions, Apono provides not just visibility but also the ability to assess risky permissions, recommend actions, and automate remediation to bring NHIs under control. 

Apono will be at Identiverse 2025, which will take place from June 3 to 6 in Las Vegas, Nevada. Attendees can learn more about Apono’s latest NHI capabilities and view a live demonstration at the Apono booth [Booth # 232] on the main conference floor and the NHI Pavilion. In addition, Apono will be a panelist during the NHI Workshop, in a session titled “The Market Landscape—Types of Solutions to Manage NHI Risks and Market Trends.” 

 More information about this platform update is available here: https://www.apono.io/securing-nhi/ 

About Apono:
Founded in 2022 by Rom Carmel (CEO) and Ofir Stein (CTO), Apono’s leadership leverages over 20 years of combined expertise in Cybersecurity and DevOps Infrastructure. Apono’s Cloud Privileged Access Platform offers companies Just-In-Time and Just-Enough privilege access, empowering organizations to seamlessly operate in the cloud by bridging the operational security gap in access management. Today, Apono’s platform serves dozens of customers across the US, including Fortune 500 companies, and has been recognized in Gartner’s Magic Quadrant for Privileged Access Management. 

Media Contact:

ICR for Apono

[email protected]

You’ve probably spent years securing human identities, employees, contractors, and admins. But there’s a growing blind spot: Non-human identities (NHIs).

Every application, microservice, API, and automated process running in your environment has an identity. They run your CI/CD pipelines, access sensitive data, and connect systems behind the scenes. These identities often hold powerful privileges that are difficult to manage without visibility and the right tools. 

Service accounts are involved in 62% of cloud breaches, and bad actors leverage compromised machine identities in lateral movement and privilege escalation attacks. With each data breach costing $4.88 million, you can’t afford to let the risks of NHIs linger in your cloud environments.

What are non-human identities, and why do they pose a threat?

Non-human identities (NHIs) are digital credentials assigned to software, services, and devices, such as API keys, service accounts, and bots, that interact with systems without human involvement. They’re essential for automation, integration, and deployment across modern development workflows.

Unlike human accounts, NHIs are often created programmatically, reused across systems, and rarely deleted. They usually rely on tokens, certificates, or access keys for authentication, and often hold elevated, persistent permissions.

Because they typically bypass standard onboarding, offboarding, and auditing processes, NHIs can accumulate stale privileges and shadow access. Once compromised, they may provide direct access to sensitive systems, making them a growing cybersecurity risk.

Aspect	Human Identities	Non-Human Identities
Identity type	A real person accessing systems and applications	A digital entity often operating without direct human intervention
Authentication method	Username/password, MFA, biometrics	API keys, secrets, certificates
Access review & scope	Periodically assessed, with privileges often constrained by role	Usually granted with high privileges
Visibility	Detectable via user behavior analysis	Often silent and anomalous behaviors are harder to detect
Risk profile	Subject to phishing and social engineering	Subject to compromised credentials, supply chain attacks, lateral movement
Lifecycle management	Governed by policies for onboarding, role changes	Often lacks formal lifecycle controls

5 Most Common Types of Non-Human Identities

Non-human identities come in many forms. If you are working in a cloud-native, DevOps-driven environment, you are already managing hundreds of NHIs, including:

1. API keys: Tokens used to establish secure communication between applications and ensure that only authorized entities gain access to APIs.

2. Service accounts: Privileged specialized accounts used by applications or services to access other systems like databases, message queues, or internal tools.

3. DevOps tools: DevOps tools like Jenkins, GitHub, and GitLab use secrets and tokens to automate CI/CD pipelines and deploy applications.

4. Robotic process automation (RPA) bots: Software robots that mimic human actions and automate repetitive, rule-based tasks such as data entry, report generation, and payment processing.

5. Cloud workload identities: NHIs like IAM roles that facilitate access to cloud resources and often operate at scale with wide-reaching access.

8 Key Risks of Non-Human Identities

1. Excessive Permissions

Granting only the necessary permissions for an identity to operate in an environment is a core cybersecurity principle. Especially when introducing new NHIs into a system, developers grant them default or overly permissive privileges during setup. It’s convenient but also dangerous, as these identities carry permissions far beyond what they need to function.

This risk also violates the principle of least privilege. If an attacker finds their way in, they can exploit the excessive permissions to cause significant damage, extract data, or shut down services.

Excessive permissions were the cause of the Microsoft OAuth application compromise in January 2024. The OAuth application acted as a non-human identity with elevated permissions, which, when compromised, facilitated broader access to internal systems. This breach demonstrated how NHIs, like OAuth applications, can be leveraged for lateral movement and emphasized the need for strict access controls and monitoring.

How to prevent it:

• Enforce the least privilege by assigning only the minimum required permissions to NHIs.
• Regularly audit whether granted permissions are actually used.
• Enable Just-In-Time (JIT) access.

2. Credential Stuffing

Credential stuffing is an attack mechanism where attackers compile massive databases of compromised credentials and reuse them across different services to gain access to NHIs with weak or reused secrets. Attackers gather these credentials from various sources, including previous data breaches, public source codes with exposed secrets, exposed configuration files, and dark web marketplaces.

If an attacker compromises an NHI, they can potentially exploit the permissions granted to the NHI to manipulate your data or software supply chain for personal gain or sell the credentials to other malicious parties.

How to prevent it:

• Use token or certificate-based authentication.
• Integrate secret vaults and rotate credentials regularly.

3. API Abuse

API abuse is a high risk when managing NHIs, as API keys typically contain complete access to services or systems. Exploitation of a poorly managed key can lead to mass data leaks and service disruptions.

For instance, the BeyondTrust Remote Support SaaS breach in December 2024 is a recent case of API abuse. Through a compromised API key (CVE-2024-12356), attackers were able to change local application passwords and gain unauthorized access.

How to prevent it:

• Implement strict API key scoping and rate limiting.
• Monitor usage patterns for anomalies.
• Rotate API keys and enforce expiration policies.

4. Hardcoded or Embedded Credentials

In many instances, developers hardcode secrets and access keys associated with NHIs into scripts, containers, and configuration files. If the repository or container image is public (or made public at a later point), anyone and everyone can easily impersonate NHIs using the exposed credentials.

How to prevent it:

• Scan the code and configuration files for secrets before deploying.
• Never store credentials in plain text.
• Use dynamic, ephemeral secrets managed by a secure, centralized system.

5. Orphaned or Abandoned Identities

When projects end, applications are deprecated, and services are decommissioned. But, NHIs often get left behind (stale/dormant NHIs) and remain active with unnecessary or escalated privileges. This risk also happens when the original owner leaves, and the associated NHIs stay active without a new owner (orphaned NHIs) instead of being offboarded.

These abandoned identities become perfect backdoors for attackers to sneak in, as no one is watching them. It can result in lateral movement and even ex-employees exploiting unrevoked credentials to access data.

How to prevent it:

• Tag NHIs with ownership metadata for better management and accountability.
• Review all associated NHIs and offboard no longer needed ones when an employee, application, or service retires.
• Use lifecycle automation to expire unused accounts.

6. Lack of Visibility and Inventory 

Losing track of many NHIs when working with large, containerized, multi-cloud environments is easy. Such systems usually contain hundreds, if not thousands, of NHIs, making it hard to track what they are doing and what permissions they carry.

The main complication with poor visibility is that if you can’t see it, you can’t secure it. As a result, unknown NHIs become unmanaged liabilities.

How to prevent it:

• Maintain a centralized, real-time inventory of all NHIs.
• Audit permissions and activity regularly.

7. Poor Credential Rotation or Long-Lived Secrets

Static credentials, especially those that last indefinitely or expire too far in the future, are common for NHIs. Even though they are convenient, they pose a significant security risk given the increased vulnerability window, and sometimes, DevOps teams lack the tooling and automation necessary to fix them efficiently.

Once exposed, long-lived secrets effectively act as access points that an attacker can exploit to invade your infrastructure without any time constraints. A dangerous example of the inadequately securing or rotating non-human credentials is the 2024 Internet Archive Zendesk token exposure. Attackers exploited unrotated API keys and Zendesk tokens to access approximately 800,000 support tickets from the Internet Archive.

How to prevent it:

• Rotate credentials frequently. Automatically, if possible.
• Use short-lived, scoped tokens and certificates.
• Enforce zero trust principles.

8. Shared NHIs Across Environments

Many organizations utilize isolated environments, such as testing, staging, and production, to ensure that issues in one environment do not affect others. However, some developers reuse the same NHIs across multiple environments for simplicity and cost reduction.

Consequently, even when an NHI associated with a low-risk environment gets compromised, it also contains permissions that an attacker can use to access sensitive production data.

How to prevent it:

• Use separate NHIs for each environment.
• Implement access controls with environment-specific scoping.

Additional Security Strategies to Combat the Risks of Non-Human Identities

Protecting against risks of non-human identities is not a one-time audit but a continuous strategy. We’ve already discussed the fundamentals—here’s the recap:

• Implementing strict access controls: Ensuring NHIs have only the permissions necessary for their function.
• Regularly rotating credentials: Preventing long-lived credentials from becoming vulnerabilities.
• Monitoring and auditing NHIs: Keeping track of non-human identities to detect and respond to suspicious activities promptly.
• Applying the principle of least privilege: Limiting NHIs to the minimal access required to perform their tasks.
• Prioritizing API security: Implementing robust API security best practices for all non-human interactions.

Plus, you can take NHI security a step further by:

• Enforcing lifecycle policies that revoke credentials when they are no longer needed.
• Regularly scanning for anomalies in NHI behavior and API usage patterns.
• Implementing Just-In-Time (JIT) access.

JIT is a powerful yet underutilized security mechanism in IAM that grants temporary access on demand and revokes it immediately afterward to shrink the attack surface and time-to-exploit. If you are looking forward to implementing JIT effectively within an IAM framework, that’s where Apono comes in.

Apono automates the JIT access flow across your entire stack and enables on-demand, self-serviced, granular permissions for just the right amount of time directly from Slack, Teams, or your CLI.

Take Control of Your NHIs With Apono

Non-human identities are rapidly expanding, posing a significant and often unseen risk to your organization’s security. Unmanaged, they can broaden your attack surface, leading to breaches that impact everything. The good news is, you don’t have to face this challenge alone.

Apono’s cloud-native access management platform is built precisely to tackle the complexities of NHI security. It automates the discovery and right sizing of permissions, ensuring that your applications, services, and bots get exactly the access they need and only the access they need. This powerful approach eliminates dangerous standing privileges across all of your identities and helps you enforce Zero Trust and least privilege principles at scale. 

With features like automated, self-service access from Slack, Teams, or your CLI and auto-expiring permissions, Apono ensures your DevOps and security teams can scale safely and efficiently, turning risky standing access to a just-in-time and just-enough model.

Learn more about Apono’s support for both human and non-human identities.
Get a demo to see Apono in action today!

At Apono, integrations are about creating seamless workflows, enhancing security, and providing exceptional experiences for engineering teams. We’re excited to announce our enhanced integration with PagerDuty because incident management and access control are truly better together.

The Challenge

When critical incidents occur, every second counts. Traditionally, gaining access to impacted resources during incidents often meant compromising security or navigating cumbersome approval processes. Shift-based approvals can overexpose production environments since shifts may include multiple escalation policies with numerous approvers. The result? Delays, security gaps, and frustrated engineers.

Our Solution: Context-Driven Access for Acknowledged Incidents

Apono’s enhanced PagerDuty integration introduces the capability of granting temporary elevated access only to the specific engineer who has acknowledged the incident in PagerDuty.

This acknowledgment-based approach helps customers achieve true least privilege principles. Now, you can build a tier-based policy hierarchy, for example, the entire on-call shift can request access to read logs, but only the developer who acknowledged the incident can request access to production environments.

Key Benefits

1. Enhanced Security: Enforcing least privilege control by restricting access only to the individual actively managing the incident.
2. Accelerated Mean Time to Resolution (MTTR): Remove access barriers that slow incident response
3. Simplified Compliance: Automatically generate comprehensive audit trails connecting incidents directly to access events
4. Improved Engineer Experience:  Reduced friction and frustration during high-pressure situations
5. Reduced Administrative Overhead: Eliminate manual approvals and access management tasks

How it Works

1. An on-call engineer acknowledges a PagerDuty incident and requests access via Apono
2. Apono verifies the incident acknowledgment status in real time.
3. Apono grants temporary access to specified resources based on an access policy configuration.
4. Access automatically expires after the set duration or can be manually revoked by administrators.
   

Getting Started

Ready to transform your incident response with precision access control? Contact our team for a demo.

The weakest link in your infrastructure might just be your permissions. In Kubernetes, permissions exist to protect your cluster, but if you’re not careful, they can become your number one problem. How?

A single misconfigured access role in a Kubernetes cluster can open the door to a full-scale security breach. Yes, your network policies and firewalls are in place, but when a bad actor can kubectl delete a namespace from inside your cluster, the real breach point is access control. 

According to Red Hat’s 2024 Kubernetes Security Report, 46% of organizations lost revenue or customers due to a container or Kubernetes security incidents like misconfigurations or vulnerabilities.

How you define and manage access really matters, which is why it’s crucial to understand the ins and outs of implementing Kubernetes RBAC effectively to help protect your business.

Kubernetes RBAC 101

While traditional identity and access management (IAM) systems handle authentication and authorization at the platform level, Kubernetes requires its own fine-grained access control mechanism.

Kubernetes role-based access control (RBAC) is a security measure used to control who and what has access to resources and applications. It allows administrators to set roles or assign specific permissions to users, groups, or service accounts. By using the principle of least privilege, users get only the required access they need and nothing more. For example, you might allow a particular user to read logs but block that user from deploying changes to production namespaces. 

​In April 2023, Aqua Security’s research team discovered that attackers found exposed Kubernetes clusters with misconfigured RBAC settings. Hackers gained access through a misconfigured API server that allowed unauthenticated requests from anonymous users with privileges. The bad actors then made API requests to gain information about the cluster and also attempted to delete some existing deployments.

Source

Roles and permissions in Kubernetes

RBAC in Kubernetes involves four key components:

• Role/ClusterRole: A Role defines a set of permissions (rules) within a namespace. A ClusterRole defines permissions across the entire cluster, including all namespaces and non-namespaced resources (e.g., nodes).
• RoleBinding/ClusterRoleBinding: RoleBinding grants the permissions defined in a Role to a user or group within a specific namespace. ClusterRoleBinding grants a ClusterRole to users/groups across the entire cluster.
• Subjects: The entities (e.g., users, groups, or service accounts) that are granted permissions via RoleBindings or ClusterRoleBindings.
• Rules: The actual permissions defined in a Role or ClusterRole. Rules specify allowed verbs (e.g., get, list, create), resources (e.g., pods, deployments), and API groups.

Users vs. Service Accounts in Kubernetes RBAC

Users and service accounts represent identities given the required permissions to carry out actions, but here’s how they differ:

Category	Users	Service accounts
Representation	Represents real users such as engineers.	Applications or processes running inside the cluster.
Authentication	External authentication (certificates, tokens, OIDC, etc.).	Kubernetes-managed tokens.
Creation	Not created through Kubernetes API.	Created through Kubernetes API.
Lifecycle	Independent of cluster state.	Tied to namespace lifecycle.

Why You Need RBAC for Kubernetes Security

Without proper access control, attackers can open the door to potential security risks. Here are a few key reasons why you need RBAC for Kubernetes security:

1. Enforces Least Privilege and Zero Trust: Different teams have different responsibilities; with RBAC, you can granularly define what each user or service account can do. This approach aligns with the principle of least privilege (a core tenet of zero trust implementation), therefore minimizing the potential damage if credentials are compromised. 
2. Supports Compliance and Auditing: RBAC provides a clear and auditable record of who has access to what within your cluster, which is crucial for meeting compliance requirements like SOC 2, HIPAA, and PCI DSS. 
3. Reduces the Impact of Mistakes or Breaches: By limiting permissions, RBAC reduces the “blast radius” of any security incident. Even in the worst-case scenario, the attacker’s access is limited to the permissions granted by their role. RBAC prevents them from moving laterally within the cluster and accessing sensitive resources beyond their assigned scope—an must-do for cyber resilience and security. 

8 Tips for Kubernetes Role-Based Access Control (RBAC)

RBAC is a powerful security measure to protect your cluster, but with great power comes great responsibility. Here are eight practical tips to help you protect your Kubernetes clusters.

1. Use Namespaces to Isolate Resources

You can have separate workspaces within your cluster so that each team or project has its own space and set of rules. For example, you can grant a developer full access to the staging namespace but limit them to read-only access in production. This way, no one can accidentally push code to production. Efficiently managing these namespaces is crucial, especially when incorporating automated testing into your Kubernetes workflows.

2. Create Custom Roles for Specific Needs

One of the biggest mistakes Kubernetes administrators make is relying on default roles. These roles might look convenient to you, but in most cases, they either give too much access or not enough.

Create custom roles and give permissions based on what people need to complete their work, which helps prevent over-permissioning. For instance, if you have a QA engineer who only needs to restart pods and read logs in the staging environment, giving the edit role might technically work, but it also gives permission to change ConfigMaps, delete deployments, or modify services—none of which is part of their job and that’s an unnecessary risk.

Instead, you can create a custom role with just get, list, and delete on pods in their namespace. Don’t give blank “edit” access when they don’t need it.

An additional tip is to combine custom roles with Just-In-Time (JIT) access, granting these finely tuned permissions only when required for a specific task and revoking them automatically afterward.

Source

3. Avoid Wildcard Permissions

This tip might be a very difficult one, but avoid using * in resources. Wildcards make it nearly impossible to track who can do what, which significantly increases the risk of privilege escalation attacks. 

For example, giving verbs and resources [“*”] means a user could delete deployments, change secrets, or access sensitive configs, whether they need to or not. Instead of doing this, always define exactly what actions are needed, like get and list on pods or create on deployments. 

Being explicit keeps your cluster safer and your access policies more readable for the entire team.

4. Apply the Principle of Least Privilege

The principle of least privilege involves giving people just enough access to do their job and nothing more. Start tight and loosen permissions only when there’s a clear need.

Why give a developer troubleshooting a broken deployment access to view logs, delete deployments, or execute into running containers? Access to view logs and describe services is enough. Any other access would mean increasing risk for no reason—keep it minimal and intentional.

Source

5. Regularly Review and Update RBAC Policies

Things change fast—your infrastructure evolves, your teams shift, and what made sense six months ago might be risky now. In a zero trust environment, where continuous verification is crucial, regular reviews are non-negotiable. You could do a permissions audit every quarter or every month. Ask questions like: 

• Has anyone left the organization?
• Are roles still aligned with responsibilities?
• Is the principle of least privilege still being followed? 

6. Use Labels and Annotations for Clarity

Labels and annotations help keep things tidy, understandable, and easy to read at first glance. It comes in handy when you’re trying to remember why a certain RoleBinding exists. For instance, adding a label like ‘team=platform’ or ‘env=prod’ can instantly tell you who the access is for and where it applies. 

Labelling also helps you understand why the role was created in the first place. This context helps when you’re onboarding new engineers who weren’t part of the initial setup. 

7. Audit and Monitor Access Logs Regularly

Setting up RBAC is a great start, but it doesn’t stop there. You also need to keep an eye on how those permissions are actually being used. Regularly checking access logs helps you catch unnecessary permissions, misused roles, or unusual behavior, like accounts doing things they shouldn’t be doing.

For instance, if a developer who shouldn’t have deployment permissions shows up in the logs trying to create resources, you can catch the issue early.

8. Use Tools to Simplify RBAC Management

As mentioned already, RBAC management can be a lot of work. Sometimes, you have to juggle creating roles, auditing access, and keeping everything up to date. It’s all too easy to make mistakes with manual provisioning, which is why broader IAM tools and automated platforms like Apono are here to help. 

For example, to integrate your cluster with Apono, you can use the Apono Connector for Kubernetes. It connects resources to Apono and separates the Apono web app from the environment for maximum security. In fact, Apono also integrates with other services, such as AWS IAM Identity Center. 

It supports both RBAC and attribute-based access control (ABAC), taking the manual work out of access management. You can also automate access flows with Apono’s features like just-in-time permissions and self-serve access requests. Engineers get the access they need only when they need it—while staying fully aligned with security and compliance standards.

Securing Your Kubernetes Cluster With Apono

Using the Apono Connector for Kubernetes makes access management easier, enabling you to manage permissions at scale, create environment-level policies, and track identities across numerous applications and cloud assets.

Apono enforces fast, self-serviced, Just–in-Time (JIT) cloud access that’s right-sized with just-enough permissions using AI. It is an easy-to-use solution that saves time by removing the need to manually provision/change roles every time a developer needs new access privileges in cloud resources, applications, or data repositories. Book a demo to see how Apono could save your team hours of waiting for access.