Small businesses are now one of the most targeted groups by cybercriminals. Attackers know that SMBs often run on lean IT teams, shared credentials and minimal oversight of who can access what. Keeper Security helps organizations of all sizes close that gap, starting with one of the most overlooked areas of security: PAM.

In enterprise environments, PAM has been a standard for years. However, for small businesses, PAM is just as critical and far less complicated to implement than most people assume.

The myth: “We are too small to be a target”

This is the most dangerous assumption in SMB security.

In reality, smaller organizations are often easier to compromise precisely because they rely on informal access habits: shared admin passwords, no offboarding process when employees leave and no audit trail of who accessed what and when. Learn more about how PAM is not only for large enterprises in our article.

The consequences of relying on shared credentials, weak offboarding processes and limited audit trails are serious. A single compromised admin account can give an attacker access to your entire network, customer data, financial systems and cloud services. For a small business, that kind of breach can be existential.

Common privileged access risks for small businesses

Most SMBs have the same blind spots when it comes to privileged access:

• Shared credentials. When multiple people use the same admin login, organizations lose visibility into who did what, and revoking access when someone leaves becomes a manual, error-prone process.
• No role-based access. Everyone gets more access than they need “just in case,” which significantly widens the attack surface.
• No session monitoring. Without visibility into privileged sessions, organizations cannot detect unusual behavior until it is too late.
• Weak offboarding. Former employees retaining access to critical systems is one of the most common sources of insider risk.

What privileged access management looks like for an SMB

As part of a broader cybersecurity strategy to help protect privileged access, here are some of the main PAM capabilities among the essential cybersecurity tools for SMBs:

• A secure password vault that stores and auto-fills credentials, eliminating insecurely shared passwords
• Role-Based Access Controls (RBAC) so each team member only accesses what their role requires
• Audit logs that record who accessed what and when
• Session monitoring and recording for high-risk connections like remote access or cloud admin panels

How SMBs can get started with PAM

The hardest part of implementing PAM for small businesses is often knowing where to begin. A practical starting point includes:

1. Audit current access. List every system, tool and account with an admin or elevated login. Organizations will likely find more than expected.
2. Identify shared credentials. Any password shared across multiple people presents an immediate risk. Replace shared credentials with individual, vaulted credentials stored in a password manager for small businesses.
3. Apply least privilege. Review who has access to what, and remove permissions not required for an individual’s day-to-day role.
4. Enable logging. Even basic audit logging provides visibility to help detect and respond to suspicious behavior.
5. Automate offboarding. Make access revocation part of every employee departure process, rather than treating it as an afterthought.

How KeeperPAM supports small business deployment 

KeeperPAM combines a secure password vault, RBAC, session monitoring and recording and audit logging into a single platform built for organizations that need enterprise-grade protection without the enterprise complexity or cost.

One of the biggest misconceptions about PAM for small businesses is that it requires a large IT team or months of planning. KeeperPAM is designed to remove that barrier; Keeper’s onboarding specialists work alongside your organization from the start, helping you get up and running within hours or days.

Whether an organization is implementing PAM for the first time or replacing an existing solution, expert guidance is available at every step.

Privileged access management for small businesses is not a luxury or a future consideration. It is a foundational security layer that protects critical accounts from the attacks most likely to cause lasting damage. The right tools make PAM accessible to organizations of any size, without unnecessary complexity or heavy lifting.

Ready to take control of privileged access? Start a KeeperPAM free trial or request a demo to see how KeeperPAM works for your business.

“This achievement is a testament to Keeper’s leadership in a market undergoing a paradigm shift, driven by the proliferation of AI in the enterprise,” said Darren Guccione, CEO and Co-founder of Keeper Security. “Forward-thinking security leaders are strategically moving beyond disparate, siloed software in favor of a unified identity control plane that offers unparalleled visibility, control and governance. They recognize that identity has become the primary attack surface, and platform consolidation is no longer just an option, but a strategic imperative. Keeper’s architecture was designed to address this complex reality, and our growth demonstrates that enterprises are decisively embracing this new direction.”

KeeperPAM consolidates password management, secrets governance, privileged session monitoring, endpoint privilege management, zero-trust network access and remote browser isolation into a single unified platform addressing the fragmentation that leaves most enterprises with visibility gaps across multiple tools. Unlike legacy identity security platforms, Keeper deploys in minutes without the complexity and cost barriers that slow enterprise adoption. The platform’s zero-knowledge architecture ensures that all credentials and session data remain encrypted with the customer’s private key, giving security teams complete control over their data.

Recent innovations driving enterprise adoption include KeeperAI, which delivers real-time session monitoring to reduce threat detection time by 99% with automated response across 100% of privileged sessions. To address the risks of autonomous agent deployment, Keeper extended agentic AI governance to Endpoint Privilege Manager, enforcing access policies, elevation controls and behavioral monitoring across both known and unknown AI agents. Concurrently, Keeper Secrets Manager integrates with Model Context Protocol (MCP) servers to secure credential access for AI agents, alongside certified enterprise connectors for platforms like Microsoft Azure Logic Apps to eliminate hardcoded secrets in automated workflows.

Platform adoption is further accelerated by deep ecosystem integrations. This includes an automated identity governance bridge with SailPoint that closes the gap between Identity Governance and Administration (IGA) and privileged access enforcement. Keeper’s integration with Wiz establishes Keeper as a remediation engine for identity security vulnerabilities discovered by the Cloud-Native Application Protection Platform (CNAPP). Additionally, Keeper has embedded privileged access and credential approvals directly into the communication and IT Service Management (ITSM) platforms organizations use every day – including Microsoft Teams, Google Chat, Slack, Jira, ServiceNow and Freshservice – enabling secure, zero-knowledge, just-in-time access requests and elevation approvals without requiring users to switch systems.

As the IAM landscape consolidates, Keeper stands as the unified identity and access platform for humans, machines and AI agents alike. For more information, visit keepersecurity.com.

Streamlining ticket management and approval

Access approvals often stall after the initial request creation. A user submits a helpdesk ticket, but the person fulfilling it has to leave that ticket, log into a separate system, track down the right record or folder and manually grant permission before reporting back. Each handoff introduces delays and moves access decisions outside of the audit trail.

The Keeper Security Freshservice Workflow App removes that handoff. When an employee submits a request through a Freshservice service catalog item, the assigned agent can search through Keeper content, configure permissions and approve or deny the request from a Keeper Vault tab inside the ticket itself. Every action runs through a customer-hosted Keeper Commander ServiceMode endpoint, so Keeper’s zero-knowledge encryption and access controls stay intact, and Keeper never stores credentials inside Freshservice’s IT Service Management (ITSM) and Enterprise Service Management (ESM) platform.

“The cryptographic boundary cannot move outside Keeper,” said Craig Lurey, CTO and Co-founder of Keeper Security. “This integration processes every approval through Commander ServiceMode on infrastructure owned and controlled by the customer, so the attack surface doesn’t expand when you wire Freshservice into your approval workflow. Freshservice is the interface for the request, never the place where secrets are stored.”

“Every access request is an identity decision, and the further those decisions drift from a governed system, the weaker the audit trail becomes,” said Darren Guccione, CEO and Co-founder of Keeper Security. “Integrating Keeper into Freshservice keeps approval decisions inside a ticketing system that security teams already trust, which means zero standing privilege and full audit control stay intact. This becomes increasingly important in the agentic era, as access requests multiply across both human and machine identities.” 

The integration also supports Endpoint Privilege Manager and Cloud SSO device approvals when paired with Keeper’s ITSM for Freshservice app, so security admins maintain a single ticketing interface for both incident-driven access requests and routine approval workflows.

Availability 

The Keeper Security Freshservice Workflow App is available now in the Freshworks Marketplace for organizations with an active Keeper Commander deployment. To learn more about the integration, visit docs.keeper.io. 

Whether onboarding a new client or expanding services within an existing account, providers often step into environments shaped by years of identity and access decisions made long before they became involved. Former employees may still have active accounts. Temporary administrator privileges may have quietly become permanent. Shared credentials can persist because replacing them would disrupt established workflows. Service accounts, API keys and integrations created for old projects may still be active.

Individually, these issues can appear relatively minor. Collectively, they create a much deeper challenge: identity security debt.

Similar to technical debt, identity security debt accumulates when short-term decisions, exceptions and incomplete processes create problems that eventually need to be addressed. But instead of outdated code or legacy infrastructure, debt exists in the identities, credentials and permissions woven throughout client environments.

For MSPs, that distinction matters. They may not have caused the debt, but they often inherit the responsibility for uncovering it, determining what access is still legitimate and reducing the overall risk it creates. And unlike a single vulnerability that can be patched, accumulated identity issues may require MSPs to trace years of access decisions, exceptions and workarounds before they can safely unravel them. 

How identity security debt accumulates in client environments

Identity security debt rarely stems from one major security failure. More often, it develops through a series of small decisions that make sense in the moment but aren’t revisited later on. 

• An employee changes roles but retains specific permissions from a previous position. 
• A contractor receives access for a six-month engagement that remains active after the assignment ends. 
• An administrator receives elevated privileges to resolve an urgent issue, but those privileges are never removed. 
• A former employee’s account is disabled in one system but overlooked in another.

The common theme is simple: Access is easier to add than it is to take away. And over time, that imbalance creates an environment where organizations may struggle to answer fundamental questions. 

• Who still has access to critical systems? 
• Which privileges are necessary for someone’s current role? 
• Which accounts belong to people who no longer work there? 
• Who approved an exception, and when was it supposed to expire?

The consequences extend beyond administrative clutter. Stale accounts can preserve unnecessary entry points, and privilege accumulation can give a compromised identity access to systems far beyond what the user currently needs. Incomplete offboarding can leave former employees, contractors or third parties with credentials that remain valid after their relationship with the organization ends.

For an MSP inheriting those types of environments, the challenge is determining which access reflects a legitimate business requirement and which simply reflects years of inherited access.

That distinction becomes harder the longer the debt remains unresolved. Removing an account or privilege without understanding its history can disrupt business operations, encouraging organizations to leave questionable access untouched rather than risk breaking something important.

The operational burden can grow alongside the security risk. Technicians may spend additional time validating ownership, tracing dependencies and determining whether an account or permission can be safely removed. During onboarding, that level of work can slow an MSP’s ability to establish an accurate baseline of the client environment and determine where the most pressing identity risks actually reside.

Identity security debt carries an operational cost. Left unresolved, it can demand increasingly more time and coordination to safely address. 

How service accounts, API keys and secrets create identity security debt

Not all identity security debt belongs to people.

Modern client environments depend on service accounts, API keys, tokens, secrets and other machine credentials that allow applications and automated processes to communicate. Unlike employee identities, these credentials can operate quietly for years without a clear owner or natural offboarding event.

A project ends, but its API key remains valid. An integration is replaced, but the original service account is never retired. A credential created for a temporary automation becomes embedded in a workflow nobody wants to disrupt. Over time, organizations inherit a growing web of machine access that may still function even when nobody can clearly explain why it exists. 

Recent research illustrates the persistence of this problem. GitGuardian’s 2026 State of Secrets Sprawl found that 64% of valid secrets first detected in 2022 were still active and exploitable four years later. Long-lived secrets also represented roughly 60% of the policy violations identified in that research.

That persistence illustrates exactly how security debt takes hold. GitGuardian notes that teams can hesitate to rotate credentials because doing so may cause production outages. Deeply embedded credentials can be especially challenging to rotate, particularly when multiple applications, repositories and workflows depend on them. 

For MSPs, discovery is therefore only the first step. Finding an old credential doesn’t immediately answer the questions that matter most: 

• Who owns it? 
• What systems depend on it? 
• What can it access? 
• What would break if it were revoked?

Those unknown dependencies can force MSPs to balance security needs against operational continuity. Leaving the credential untouched preserves unnecessary access, but removing it without sufficient context could also disrupt a client’s core operations. What initially began as a small lifecycle oversight can eventually require extensive investigation and coordination across multiple systems. 

Without that context, even identified issues can linger. 

And that’s exactly how debt compounds.

Why shared credentials create security and accountability risks

Some identity security debt persists not because it’s forgotten, but because it’s convenient.

Shared credentials are a primary example. An operations team needs access to an administrative portal, so one login is distributed among several co-workers. A legacy application doesn’t support individual accounts. A client has always managed a particular system that way, and changing the process seems more burdensome than leaving it alone. 

The immediate benefit is simplicity, but the long-term cost is accountability.

When multiple people operate through the same identity, individual accountability becomes much tougher to establish, particularly when determining who accessed a system, changed a configuration or exposed a credential. 

Offboarding presents another challenge. When one employee leaves, the credential may need to be rotated for everyone. If that doesn’t happen, knowledge of the login can outlive the person’s legitimate need for access. 

The problem can extend into auditing and compliance efforts, too. Clients may be asked by auditors, cyber insurers, regulators or even their own customers to show who accessed sensitive resources, when that access occurred and whether it was authorized. Shared identities weaken that chain of accountability, leaving MSPs and their clients with less reliable evidence when they need to reconstruct activity. 

These workarounds can also become increasingly entrenched over time. The more users, systems and processes that depend on a shared credential, the harder replacing it becomes.

That’s another characteristic of debt: short-term convenience can lead to lasting operational burden.  

What MSPs should look for when assessing identity security debt

Reducing identity security debt starts with determining how much already exists. 

That makes identity discovery and lifecycle review especially important during client onboarding, when MSPs are establishing their first accurate picture of who and what has access across the environment. But the process can’t end there. Roles change, contractors come and go, new integrations appear and temporary exceptions are created throughout the client relationship.

MSPs should regularly examine questions such as:

• Which inactive or former-user accounts still retain access?
• Which temporary privileges lack a defined expiration date? 
• Which users have retained permissions from previous roles? 
• Which service accounts, API keys and secrets lack clear ownership?
• Which contractor, vendor or guest accounts remain active?
• Where are credentials shared rather than individually assigned?
• Which integrations still have access despite no longer serving an active business need?

The objective isn’t simply to identify more accounts. It’s to distinguish between access a client actively needs and access that has persisted beyond its original purpose. 

That distinction gives MSPs a clearer picture of where excess exposure exists, which issues deserve priority and where corrective action should begin. More importantly, it creates a baseline to evaluate future access decisions, making it easier to recognize when new debt starts to emerge. 

Stop identity security debt from compounding

Not every piece of identity security debt can be eliminated immediately. Legacy systems may remain in production and service accounts may require careful migration. Removing undocumented permissions without first identifying their dependencies can interfere with critical business processes. 

The goal is to keep short-term exceptions from developing into long-term identity debt. 

That requires stronger lifecycle discipline: retiring stale identities, reviewing access as roles change, assigning ownership to machine credentials, replacing standing privilege with time-bound access where possible and ensuring temporary access actually expires.

Keeper offers MSPs a unified identity security platform to put those principles into practice across client environments. By consolidating enterprise password management, privileged access management, secrets management and endpoint privilege management within a zero-knowledge, zero-trust architecture, Keeper helps providers protect credentials, reduce unnecessary standing access and manage both human and non-human identities at scale.

For MSPs, reducing identity security debt goes beyond cleaning up what clients did in the past. It’s about establishing stronger access practices that prevent old patterns from repeating and keep new decisions from adding to the burden. 

Because identity security debt doesn’t disappear with time; it compounds. 

Explore the Keeper MSP Partner Program and learn how Keeper helps MSPs bring greater control to identity and access across client environments.

Launched in June, Keeper Privileged Cloud has delivered just-in-time, zero-standing privilege access across cloud platforms, identity providers and federated applications – including AWS IAM, Microsoft Entra ID, GCP, Okta and Active Directory. Rather than relying on shared privileged credentials, it grants temporary elevated access by modifying a user’s identity-layer membership or role assignment for an approved, time-bound window. Admins configure each PAM record with a target group or role, approval requirements, access duration and MFA enforcement – then share the record with eligible users who can request elevation directly from the Keeper Vault. Once approved, KeeperPAM applies the temporary entitlement in the identity platform and the user can launch the target resource through Remote Browser Isolation or their standard SSO and CLI workflows. When the access window closes, KeeperPAM automatically revokes the elevation, leaving no standing privileges behind.

Synchronize shared secrets to cloud secret management services with Universal Secrets Sync

Universal Secrets Sync (USS) automatically pushes secrets from the Keeper Vault to AWS Secrets Manager, Azure Key Vault and Google Cloud Secret Manager – making Keeper the single source of truth for all cloud secrets. When a record is created or updated in Keeper, every connected cloud provider receives the change automatically, eliminating the secrets sprawl and manual copy-paste that leads to stale credentials and security incidents. The Keeper Gateway handles all sync operations locally, decrypting and writing secrets directly to the cloud provider so plaintext never touches Keeper’s infrastructure. Admins can sync across multiple folders, assign a least-privilege Sync Identity per provider, and use dry-run mode to preview changes before committing, with every operation logged in the Keeper audit trail and surfaced through Keeper’s Advanced Reporting and Alerts Module (ARAM).

Endpoint Privilege Manager Agentic AI governance

Keeper’s Agentic AI policy gives security teams control over which AI agents are permitted to run on managed endpoints, including coding assistants like GitHub Copilot, Cursor and Claude Code, as well as containerized agents and unknown agent-like processes. Agents are recognized by signature or a behavioral heuristic engine that scores unknown processes on how closely they resemble an AI agent, enabling confidence-based controls over both known and unrecognized activity. Admins can auto-allow sanctioned agents, block unsanctioned ones outright or require approval, MFA and justification before any agent executes. Every outcome is logged for full auditability across the managed endpoints.

KeeperDB adds NoSQL support, multi-connection workflows and stronger authentication

KeeperDB now connects to MongoDB and Amazon DynamoDB, extending the tool’s coverage to NoSQL databases alongside its existing SQL support, each with a native query experience (MongoDB shell syntax, DynamoDB PartiQL). Users can now open multiple database connections at once across different engines, each in its own tab, and run a broadcast query across several same-engine connections simultaneously to compare results. SQL Server and Azure SQL now support signing in with Microsoft Entra ID delegated user tokens as an alternative to static credentials. Oracle and SQL Server connections are also more resilient, with better detection of and recovery from dropped sessions, and a new Test Connection button lets users validate credentials before opening a session.

Keeper Commander now available as a ClawHub skill

Keeper Commander is available as an installable skill on ClawHub, bringing the full range of Keeper CLI workflows into OpenClaw agent environments. The skill covers setup and profile configuration, vault and admin search, secret retrieval and field-level injection, as well as record creation and updates. The skill also features built-in guardrails that keep secrets out of chat, disk and version history. A dedicated tmux session is required for interactive work to preserve authentication state across commands. Engineers and DevOps teams can install it in one command via the OpenClaw CLI and start running Keeper workflows immediately.

Hierarchical record sharing arrives with Nested Shared Folders

Keeper has introduced Nested Shared Folders, a rebuilt vault permissions model that gives teams a more flexible and scalable way to organize and share sensitive records. Folders can be structured up to five levels deep with independent sharing configurations at each level. Role-based permissions can be applied through inheritance, direct folder assignment or direct record assignment, with the most specific assignment always taking precedence. Five permission types ranging from Viewer to Full Manager give administrators precise control over who can view, edit, share and manage content, with support for bulk permission changes, access expiration and immediate revocation. The Classic folder system remains fully supported with no forced migration and both systems can operate in parallel during the transition. Nested Shared Folders is currently available by invitation only – contact your Keeper representative or visit keepersecurity.com/contact to request access.

Commander Terraform brings KeeperPAM infrastructure as code

Keeper’s Terraform module for Commander enables teams to define and deploy privileged access environments entirely as code, from PAM Configurations and Gateway associations through to target machines, users, databases, directories and remote browsers. A new commander_pam_configuration resource covers KeeperPAM capabilities including connections, tunneling, rotation, remote browser isolation and session recording, while new resources for all classic PAM record types bring per-user share permissions directly into Terraform. This release also adds Keeper Secrets Manager application management as code and expands folder management with support for Nested Shared Folders and private non-shared folders.

KeeperPAM automates Windows service and scheduled task credential rotation

KeeperPAM Password Rotation automatically manages logon credentials for Windows services, scheduled tasks and IIS pools, ensuring that when a PAM User record is rotated, the Keeper Gateway updates and restarts all associated services across every linked machine in one operation. A single PAM User record can be mapped to any number of PAM Machine records, making it practical to propagate a credential change across an entire fleet of Windows servers without manual intervention. Service associations can be configured directly from the Keeper Vault, discovered automatically through a Discovery job or managed via the Commander CLI using pam action service commands, giving teams flexible setup and management paths. When rotation is triggered, actively running services are restarted automatically with the new credentials, while stopped services remain stopped until manually started.

KeeperPAM integrates with Wiz for closed-loop cloud security remediation

KeeperPAM integrates with Wiz CNAPP, creating a direct automated path from cloud security finding to remediation and eliminating the need to manually track and coordinate across tools. When Wiz identifies an exposed identity or resource, it is onboarded into Keeper immediately. Admins can resolve findings through just-in-time access, credential rotation or privileged access protection for machines, databases and users directly from the Keeper Cloud Security dashboard. Wiz is automatically notified of remediation status as findings move from open to in progress to resolved and every action is logged with a full audit trail to support compliance. The integration significantly reduces mean time to remediate by shrinking the window between discovery and action before a vulnerability can be exploited.

Non-Human Identity visibility comes to the Admin Console

Admin Console delivers a major step forward in Non-Human Identity (NHI) management, giving administrators a dedicated KeeperPAM tab that brings Secrets Manager, Gateways and Connection Manager together in one place. A new centralized PAM dashboard surfaces NHI tier overviews, near-limit and over-limit alerts, and PAM usage by user. The updated Secrets Manager dashboard adds tier metrics and usage cycle tracking. The Subscriptions tab now shows expanded PAM entitlement details including managed and available license counts, active NHI usage against tier thresholds, and a direct in-console link to upgrade tiers, giving administrators full visibility into their KeeperPAM footprint without leaving the console.

Vault Connection Dock and PAM Configurations as native vault records

We’ve introduced the Connection Dock, a new panel in the upper-right corner of the Keeper Vault that gives users a centralized view of all active and recently closed PAM sessions. From the dock, users can monitor connection status, relaunch recently closed sessions, close active ones and access record details directly from the session log, making it easy to switch between or resume privileged sessions without leaving the vault. PAM Configurations are now also accessible as native vault records in the My Vault screen, bringing them into the same sharing, organization,and management workflows used for standard records and eliminating the need to manage them separately. This release also adds quantum-resistant cryptography for the transmission layer and new ARAM audit events for masked field reveals.

Centralized identity governance for Keeper, powered by SailPoint

Keeper integrates with SailPoint Identity Security Cloud, giving organizations centralized governance over Keeper vault access from directly within SailPoint. With the Keeper Security SailPoint SaaS Connector, administrators can aggregate accounts and entitlements, provision new Keeper vaults and assign roles, teams, folders and records – all without leaving SailPoint. Rather than managing vault access separately, security teams can govern Keeper alongside every other enterprise system, ensuring users have exactly the right permissions at the right time. Access is automatically kept in sync as users join, change roles or leave, reducing the risk of orphaned accounts and over-privileged users. Throughout it all, the connector communicates through Keeper Commander Service Mode, keeping your organization’s zero-knowledge encryption model fully intact.

Keeper Secrets Manager available as a certified Azure Logic Apps Connector 

We’re excited to announce that Keeper Secrets Manager (KSM) is now available as a certified connector on the Microsoft Power Platform marketplace, bringing seamless secrets management to Azure Logic Apps and Power Automate workflows. Teams can now retrieve, create, update and rotate credentials directly from their automation flows at runtime, with all secrets protected by Keeper’s zero-knowledge architecture, decrypted locally inside your Azure environment and never passing through Keeper’s servers. Setup takes just minutes via a one-click ARM template that provisions all required Azure resources automatically, and dynamic dropdowns for secret and folder selection are built right into the Logic App designer. Common automation patterns including scheduled password rotation, employee credential provisioning, GitHub secret sync and vault compliance auditing are ready to build out of the box, integrating Keeper directly into the workflows your team already relies on.

Browser Extension levels up with smarter autofill and granular site controls

The latest version of the Keeper Browser extension features a fully redesigned autofill experience and a new way to pause Keeper on any site. Autofill suggestions now appear inline beneath form fields as you click or tab into them – no hunting through pop-ups. Suggestions filter in real-time as you type and multiple saved logins appear in a scrollable list sorted by favorites and recent use. Additionally, the new Hide Keeper feature lets you silence autofill and the Keeper icon on any site with a single click, with easy restoration from the toolbar or Settings menu. We’ve also introduced field-level detection for more accurate autofill, available as an opt-in feature while we continue to refine it. Go to Settings > KeeperFill Tool and toggle “Enable New Autofill Prompt” on to give it a try. 

Various improvements to the Commander CLI

Keeper Commander is constantly improving. Here are some of our newest commands:

• pam project cyberark-import – automated migration of safes, accounts, platforms and policies from CyberArk
• import –format bitwarden – import Bitwarden collections with automatic folder mapping
• pam connection edit / pam import – support for 10+ databases: MariaDB, Oracle, MongoDB, Redis, Elasticsearch, ClickHouse, DynamoDB and more
• pam connection ai – KeeperAI for PAM Resources
• pam rbi edit – control session persistence, file policies and audio settings for RBI
• nsf – Nested Shared Folders and permissions are now supported
• pamGitHubConfiguration – PAM now supports GitHub configuration record types
• $GEN:passphrase – generate passphrases
• CNAPP integration commands

For a full list of Keeper Commander updates, visit our Release Notes.

Keeper’s Google Chat App integration addresses a critical gap for organizations that use Google Workspace as their primary collaboration platform, enabling administrators to manage privileged access without switching to separate tools. Teams can now submit vault access requests with justification and custom permission levels, retrieve secrets and approve just-in-time elevation requests with full audit trails and reporting. Administrators enforce time-limited access windows and policy-driven approval routing through Keeper without requiring users to navigate multiple systems.

“Organizations need access controls embedded in the tools their teams already use,” said Craig Lurey, CTO and Co-founder of Keeper Security. “Using this integration means your infrastructure stays isolated because the chat app is just the interface. The encryption and verification happen entirely in your environment, so credentials never exist in transit, whether to Google’s infrastructure or ours.”

Seamless access without exposure

The Google Chat App runs on an organization’s existing infrastructure using Commander Service Mode. Credentials remain encrypted end-to-end and never pass through external services, maintaining the same zero-knowledge model as Keeper’s core platform.  Administrators have a variety of actions available through the integration that reduce the burden of manually switching between tools, increasing both security and productivity. 

The integration supports:

• Vault record access requests with custom permissions and time-limited sessions to eliminate waiting for credential distribution
• Endpoint Privilege Manager elevation approvals for just-in-time privilege escalation to reduce approval friction
• SSO Cloud device approvals for federated authentication workflows to streamline device onboarding
• Real-time request notifications and approval workflows within dedicated channels to keep approvers in flow
• Centralized audit logging of all access requests, approvals and credential access to ensure compliance visibility

The integration is available immediately to Keeper customers with active Keeper Secrets Manager or KeeperPAM licenses. Installation is facilitated through a guided setup process that uses Keeper Secrets Manager to securely store the integration’s configuration and credentials. For setup details and user documentation, visit docs.keeper.io. 

Continue reading to learn how traditional security models have become insufficient, why AI expedites the speed at which OT weaknesses can be found by attackers and how to apply zero trust to OT environments to protect critical infrastructure.

How the traditional security model fails in critical infrastructure

Internet-exposed controllers, default credentials and always-on vendor access are known weaknesses, and none require sophisticated technology or expertise to exploit because they rely on trust assumptions. A flat or lightly segmented network assumes that anything already inside belongs; an engineering workstation with reach into all controllers assumes the person at the keyboard is who should be there. Similarly, a default password assumes the device sits somewhere an outsider cannot reach.

The U.S. water cyber attack exposed a quieter version of the same underlying issue: Some reachable equipment consists of cellular modems and devices installed by vendors that are never captured in routine security scans. Most of these environments were designed under conditions where every assumption was made at installation and inherited by every team since then without ever being re-examined. Nobody intends to leave a PLC on the public internet, but IT/OT convergence has moved the boundary in recent years, and the trust map hasn’t been adjusted to match.

Why AI shortens the time you have to fix OT weaknesses

In joint advisory AA26-231A, issued on August 19, 2026, the NSA, CISA, FBI, Department of Energy and Environmental Protection Agency reported that cybercriminals are using AI-generated scripts, disguised as legitimate monitoring utilities, to conduct reconnaissance against internet-exposed Siemens S7 Series PLCs. The agencies warned that AI-assisted development can lower the technical barrier and reduce the time required to create exploitation tooling. The advisory does not describe new zero-day vulnerabilities, and the activity it observed is reconnaissance rather than confirmed disruption. The weaknesses are the same ones already in federal advisories, but what’s changed is who can act on them and how quickly.

AI-driven security concerns are also extending to the identity side. On August 27, 2026, more than 100 organizations signed an open letter on collective cyber defense warning readers that AI-enabled cyber attacks could become more widespread soon, naming hospitals, water treatment plants and internet infrastructure among the systems at risk and calling for support for under-resourced critical infrastructure defenders.

How zero trust for critical infrastructure changes OT security

Zero trust is a security model that removes implicit trust; instead of granting access based on network location, it verifies every user and device by identity, limits access to the minimum required and logs activity. In OT environments, zero trust means being on the control network no longer entitles anyone to reach the equipment on it. Now, there is a shift in what needs to be defended, which is why zero trust works in environments where the boundary has already dissolved, and the equipment behind it cannot be replaced.

Identity becomes the control point, not network location

Every human, vendor, service account and AI agent that touches your environment gets a verified identity, and access decisions are made against that identity rather than an IP address. A shared operator login fails this test instantly because it identifies a role, not a person. The AI industry has put the same standard on record for its own systems. The collective letter states that agentic identities should be traceable and accountable — a commitment from the companies building these agents, not a directive to infrastructure operators. It’s still worth holding your AI vendors to that standard and applying it to any agent running in your environment to ensure AI agents do not have standing access.

Least privilege and JIT access are the priority, not standing access

Consider an integrator who services a treatment plant every six months and needs several hours of access each time. Under a traditional cybersecurity model, that vendor holds a permanent VPN account, which means their credentials remain a live path into your network for the rest of the year, protected only by their internal security practices. Just-in-Time (JIT) access inverts that; the account is provisioned only when the work is scheduled, scoped to the specific system and revoked automatically when the window closes. Zero-Trust Network Access (ZTNA) enforces the same principle for the connection itself; instead of placing the vendor on your network like a VPN does, it connects them to one system and makes nothing else visible.

Limit the blast radius across the IT/OT boundary

Containment assumes someone will eventually gain access and questions how far they can go with that access. Segmenting the IT/OT boundary, restricting which engineering workstations may communicate with which controllers and eliminating standing access all minimize the blast radius. The same logic applies to AI agents operating across your systems, where permissions accumulate quickly and quietly. Try our AI agent blast radius calculator to see how far a single compromised AI agent could reach.

Continuously verify, monitor activity and record sessions

Login verification requires one check, but continuous verification re-evaluates access as conditions change and revokes access when they do. Session monitoring and recording capture exactly what happened during a privileged connection to a controller, turning a suspicious event into something you can investigate rather than reconstruct after the fact.

How to apply zero trust to OT environments

In OT environments, the main security priorities are availability and safety because a control system going down means people may not get water or power. CISA’s guidance on adapting zero-trust principles to OT maps zero-trust outcomes to six NIST CSF 2.0 functions while clearly accounting for legacy gaps, operational constraints and safety requirements. The guidance recognizes that zero-trust principles must be adapted to OT environments rather than applied identically to traditional IT systems. That’s the practical case for zero trust in OT. Advisory AA26-231A also tells operators to use compensating controls when a legacy device cannot be patched or reconfigured without a planned outage, and the collective letter makes the case for the same strategy. An outdated controller may not be able to be patched, but who reaches it, from where and for how long can be controlled and monitored. Here’s where to start when applying zero trust to OT environments:

Protect your critical infrastructure with Keeper

Recent cyber attacks and federal advisories show why critical infrastructure organizations need stronger controls around privileged and remote access, particularly when legacy OT cannot be quickly patched or replaced. Organizations can reduce risk by controlling who can access critical systems, what resources they can reach, how long access lasts and what actions they can take. KeeperPAM® helps critical infrastructure organizations secure and manage privileged access across IT and OT environments. Through the Keeper Gateway, it provides secure remote access to infrastructure without opening inbound firewall ports or exposing credentials to end users. Built on a zero-trust and zero-knowledge architecture, KeeperPAM also supports JIT access, automated credential rotation, least-privilege access and privileged session management. Start a free trial of KeeperPAM to close the access paths attackers are already scanning for.

For most organizations, identity governance and privileged access management have operated as separate systems with no automated handoff between them. IGA platforms define who should have access, managing the approvals, controls and certifications that keep organizations compliant. PAM platforms enforce that access, delivering just-in-time access to privileged identities and resources secured in a zero-knowledge encrypted vault. Without a connection between the two, every access decision made in governance had to be manually carried out in the vault – and every role change, revocation or offboarding risked leaving privileged credentials behind. That cleanup fell to manual processes that were slow, inconsistent and error-ridden. Keeper’s 2026 research found that 96% of senior IT leaders say disconnected security tools are creating exploitable gaps, and 64% do not yet operate with fully consolidated privileged access governance.

Keeper’s tight integration with SailPoint is unique. Provisioning of vaults, assignment of roles and entitlements defined in SailPoint are seamlessly provisioned into Keeper automatically across team memberships, shared folders, roles, nodes, records and administrative permissions. Access certifications cover the privileged credentials Keeper holds, so reviews reflect actual access. Organizations can configure which entitlement types SailPoint manages within Keeper, and credentials are never exposed to SailPoint throughout the process, preserving Keeper’s zero-knowledge architecture. Every grant, update and revocation is logged automatically across both platforms.

“The organizations that properly implement identity security understand that governance is only as strong as its enforcement,” said Darren Guccione, CEO and Co-founder of Keeper Security. “Seamless integration between IGA and PAM covering any type of human and non-human identity is an enormous gap for most enterprises. Our integration with SailPoint solves this.”

Keeper is FedRAMP High Certified, FIPS 140-3 validated and listed on the CISA Continuous Diagnostics and Mitigation (CDM) Approved Products List. For federal agencies, the integration directly supports compliance with NIST Special Publication 800-53 Rev. 5 requirements for account management, least privilege enforcement and privileged credential control. When SailPoint runs a scheduled access certification, the review now includes the privileged credentials, NHIs and identities being managed by Keeper, giving auditors a complete and reconciled record across both platforms.

The Keeper integration with SailPoint is available now. For organizations running SailPoint for identity governance and KeeperPAM for privileged access management, the integration eliminates the manual reconciliation work that has sat between those two systems. For more information, visit Keeper Security’s integrations.

Continue reading to learn more about secrets configuration drift, where secrets drift, how to detect secrets configuration drift and ways to eliminate it.

What is secrets configuration drift?

Secrets configuration drift occurs when the credentials, keys and other secrets deployed across a cloud environment no longer match the intended state defined in a centralized vault. The desired state is what the vault defines as authoritative, whereas the actual state is what applications and services actually use across cloud secret stores, CI/CD pipelines, .env files and workloads. These two states diverge when teams make manual or unplanned changes outside managed workflows, rotate secrets without propagating the new values to dependent systems or allow secrets sprawl to create unmanaged copies across environments. As those gaps accumulate, the vault can remain the source of truth on paper while no longer reflecting the secrets actually running in production.

Secrets configuration drift vs configuration drift

Secrets configuration drift is a specific kind of configuration drift, but the main difference is what actually drifts. Configuration drift occurs when the actual state of infrastructure, such as servers and ports, gradually diverges from the intended baseline defined in code or configuration files. Secrets configuration drift applies the same concept to credentials — passwords, API keys, tokens and other secrets — running in cloud environments that no longer match the intended state maintained in the vault.

Infrastructure drift mainly threatens operational consistency and availability, while secrets configuration drift can create direct security exposure. An unreconciled credential may stay valid outside the managed workflow, making it more difficult to enforce least-privilege access, verify rotation and prove that privileged credentials are properly controlled during an audit.

Where do secrets drift?

Secrets can drift anywhere you copy, sync or change credentials outside your centralized vault. The more systems that keep their own version of a secret, the more chances there are for the vault’s intended state to diverge from what’s actually deployed.

Broken or incomplete sync to cloud secrets managers

You may sync secrets from your vault to cloud-native secrets managers. If that sync fails, is misconfigured or only partially completes, a secret can change in one place without updating in another. As a result, you may be left with two different versions of the same credential with no reliable signal for which one is authoritative.

Secrets copied into CI/CD and images

Developers may copy secrets into CI/CD variables, config files or container images to make them available at runtime. Those static copies don’t update when the original secret rotates in the vault, so you accumulate stale credentials that are difficult to find, track and revoke.

Manual break-glass changes

During a security incident, an administrator may need to edit a credential or grant access directly in the cloud console to restore production. The immediate problem will be resolved, but if the emergency change never makes it back to the vault, your vault no longer accurately reflects the access that actually exists.

Policy and permission drift

Drift can also impact who or what has permission to use a secret. Access policies gradually diverge across accounts, clusters and environments as users make small changes over time. For example, a role that’s supposed to have read-only access everywhere could gain broader permissions in one environment. Without centralized reconciliation, least-privilege access quietly erodes.

How to detect secrets configuration drift

Detecting secrets configuration drift means keeping continuous visibility into the desired state in your vault and the actual state across your cloud. Instead of depending on periodic manual reviews, monitor for discrepancies and out-of-band changes as they happen.

Steps to eliminating secrets configuration drift

Eliminating secrets configuration drift requires you to control where your secrets originate, how they reach downstream systems and who can change them. The following steps help keep the desired state in your vault aligned with the actual state across your cloud.

1. Establish one source of truth for every secret

Make one centralized vault the authoritative source for credentials, keys and other secrets. Your applications and cloud environments should pull secrets from this vault rather than keeping their own versions. Having a clearly defined source of truth makes it possible to identify when a secret has drifted and which value to trust.

2. Make sync one-way and automated

Automate the flow of secrets from your vault out to downstream cloud secret stores, and restrict users from making manual edits in cloud consoles wherever possible. An automated, one-way workflow stops competing sources of truth from forming and reduces out-of-band changes that can create drift in the first place.

3. Rotate and propagate

Automated rotation is only effective if every system that uses the secret receives the new value. Integrate rotation into your downstream applications and environments so that when a credential changes, authorized consumers get the updated secret and outdated versions are revoked. Rotating a secret in the vault without updating its copies just creates a new form of drift.

4. Enforce least privilege

Apply least-privilege access consistently across your cloud accounts, clusters and environments so each user and workload can reach only the secrets required for its role. Centralized access controls make it more difficult to create unauthorized grants or modify secrets outside approved workflows, preventing permissions from quietly diverging between environments.

5. Add continuous reconciliation and alerting

While detection tells you that drift happened, reconciliation is important in closing the gap. When your vault’s desired state and the actual state in the cloud differ, reconcile back to the vault’s authoritative value — either automatically where it’s safe or through an alert when a human user should be involved. This turns drift detection into an ongoing control rather than something an audit or security incident can uncover later.

6. Stop secrets sprawl

The fewer places a secret lives, the fewer places it can drift. Consolidate unnecessary secret stores, discover and remove orphaned credentials and eliminate secrets from source code, CI/CD configs, container images and .env files. Less secrets sprawl means fewer unmanaged copies, making every remaining secret easier to inventory, rotate and control.

How Keeper^® helps eliminate secrets drift

Keeper handles secrets configuration drift at the source with Universal Secrets Sync (USS), a KeeperPAM feature that syncs secrets from the Keeper Vault to cloud-native secrets managers like AWS Secrets Manager, Azure Key Vault and Google Cloud Secret Manager. Instead of finding a mismatch after the fact, USS helps prevent drift by making the Keeper Vault your authoritative source and automatically pushing out every change to configured cloud environments. Paired with Keeper Secrets Manager, USS operates inside KeeperPAM, which centrally rotates infrastructure secrets and distributes the updated values across your cloud environments all within Keeper’s zero-trust, zero-knowledge architecture.

End secrets configuration drift with Keeper

A vault only remains a source of truth if reality matches it. By continuously enforcing the desired state through centralized management, automated sync and least-privilege access, you can keep secrets from quietly drifting and creating unnecessary security risks. Keeper’s Universal Secrets Sync does this by automatically syncing secrets from the Keeper Vault to downstream cloud secret managers.

Start a free trial of KeeperPAM to see how USS can help ensure your vault and cloud environments stay in sync.

The report recognizes Keeper’s continued innovation, architectural depth and ability to help organizations secure more than just passwords. With Keeper, enterprises can protect credentials, secrets, machines, non-human identities and AI agents from a single, unified platform. Request a demo today to see firsthand why we are ranked so highly.

Report overview and key highlights

GigaOm’s 2026 Radar Report examines 23 leading enterprise password management solutions. It evaluates each provider against a range of capabilities, including table-stakes, key and emerging features, as well as broader business criteria.

The Enduring Innovators quadrant recognizes platforms that continue to build on their market position through ongoing innovation and strong underlying architecture. Keeper was recognized as advancing faster than the majority of the field, with particular strengths in secrets management, its official Model Context Protocol (MCP) server and governance for agentic and non-human identities.

This is the fifth year that GigaOm has evaluated the enterprise password management market  and the fifth consecutive year that Keeper has earned a Leader designation.

How Keeper stands out 

Unlike fragmented tools or limited vault-only solutions, Keeper provides a zero-trust, zero-knowledge security architecture for protecting credentials and access across the enterprise. Key strengths include: 

• Compliance-ready security: FedRAMP High Certified and GovRAMP High Authorized, FIPS 140-3 validated, with longstanding SOC 2 and ISO certifications.
• One platform for every identity: Govern human, machine, non-human and AI agent identities from a single control plane.
• Built-in secrets management: Protect credentials used by developers, applications, services and infrastructure.
• Secure access anywhere: Use Keeper across desktops, mobile devices and browsers.
• Fine-grained controls: Apply least-privilege principles with time-limited access, one-time sharing and self-destructing records.
• Broad integrations: Connect with SSO, MFA, SIEM, CI/CD tools and passwordless authentication.
• Fast deployment: Deploy in minutes alongside existing tools, no disruptive rip-and-replace required.

Innovation since the last GigaOm report

The identity security landscape is changing quickly, with AI agents, machine identities and non-human accounts becoming part of everyday business operations. Keeper has responded by continuously expanding its platform to help organizations manage these identities alongside their workforce.

The latest capabilities include AI agent governance, an official MCP server, real-time threat detection through KeeperAI, improved risk visibility and stronger session protection. Keeper has also expanded passkey and passwordless authentication, while KeeperPAM brings password management, secrets management, privileged access management and endpoint privilege management together in one unified identity security platform.

Together, these updates give security teams greater visibility and control as identity environments become more complex. To see the full Keeper platform beyond just password management, request a demo of KeeperPAM.

Why enterprise password management matters

Weak, reused or exposed credentials can leave organizations vulnerable. Enterprise password management helps security teams protect passwords, secrets and machine credentials while enforcing access policies, supporting passwordless authentication and maintaining clear audit trails.

Password management is about more than just storing passwords. It provides centralized control and visibility across users, devices, applications and identities.

Try Keeper for free

Protect your organization’s passwords, credentials and secrets with zero-trust and zero-knowledge security. Sign up for a free 14-day trial or reach out to our team to learn more.

Looking to secure your organization beyond password management? Learn more about KeeperPAM®

Strengthen your organization’s security posture by investing in a privileged access management solution that supports a zero-trust strategy. KeeperPAM is both zero trust and zero knowledge, which helps prevent unauthorized access and ensures that only the right users have the appropriate level of access. With features like endpoint privilege management, role-based access control, Just-in-Time (JIT) access and detailed auditing, monitoring and session recording, KeeperPAM helps your organization secure critical data and maintain tight controls over all infrastructure. 

To learn more about how KeeperPAM can secure your organization with its zero-trust strategy, request a demo today. 

Continue reading to learn the importance of ZSP, how it works in Keeper and where Keeper enforces it across environments.

Why standing privileges are a security risk

A privileged account that stays active indefinitely gives attackers a long-lasting target: the credentials don’t expire, the access is constantly available and there’s no given moment when those rights are taken away. If attackers steal or compromise one of these accounts, they inherit standing privileges in their entirety.

The bigger problem is blast radius since a compromised account with standing access rarely stops at the system for which it was intended. Attackers use standing privileges to move laterally across environments, reaching additional servers, databases and cloud resources in their paths. What may begin as a single compromised credential can quickly turn into a foothold across your entire infrastructure if the user has standing access. When privileges are permanent, access isn’t tied to a specific request, task or timeframe, leaving no clear record of why someone could reach a system at a certain moment. That ambiguity makes investigating security incidents involving standing privileges and proving compliance much more challenging.

How zero standing privilege works in Keeper

Keeper helps enforce ZSP through Keeper Privileged Cloud, which extends KeeperPAM’s JIT access framework to your identity providers and federated applications. Instead of provisioning permanent admin rights, Keeper Privileged Cloud grants elevated access only when it’s requested, only for an approved time window and only under the workflow controls you define. Users default to no privilege and elevate through a controlled, auditable process, then return to zero when the task is done. Below is how ZSP works in practice for Keeper.

Configure access policies

On a PAM Cloud record, admins define the rules of engagement using JIT and Workflow settings. This includes whether a request needs approval, who can approve it, how long access lasts once granted and which role the user is elevated into. These settings help determine exactly how privileged access is requested, approved and time-boxed, ensuring no elevation happens beyond the boundaries you set.

Share records with authorized users

Once a policy is in place, the PAM Cloud record is shared with the users who should be able to request access. Because elevation happens through your identity provider, each user needs an account in both your identity provider and Keeper tenant. With the record shared, those users can request elevated access when a task calls for it, without holding any standing privilege in the meantime.

Review and approve requests

When a user needs access, they can request it directly from their Keeper Vault or the Keeper Commander CLI. Designated approvers receive real-time notifications from tools like Slack, Teams, Jira and ServiceNow and can either approve or deny a request from any Keeper client, so requests aren’t stuck waiting for someone to be at their desk. Depending on the policy, approvers can also require a justification and a ticket number before granting access, linking every elevation to a documented reason.

Grant and revoke access automatically

After a request is approved, the Keeper Gateway performs the elevation on the identity provider or target resource, granting the user the configured group membership, role or entitlement so they gain the access the policy allows. When the approved duration expires, the Keeper Gateway automatically revokes that access, removing the temporary membership or assignment and returning the user to ZSP. It also records every elevation that requested access, who approved it, and when it started and ended so security and compliance teams have a clear, per-request account of how privileged access was granted and used.

Where Keeper enforces zero standing privilege

Keeper doesn’t confine ZSP to a single system or account type. The same JIT framework applies wherever privileged access exists in your environment, from the identity providers your users authenticate against to the cloud resources, databases and machines behind them.

Across your identity providers

Keeper Privileged Cloud extends JIT access across existing identity providers, including AWS IAM, Microsoft Entra ID, Google Cloud via Google Identity, Okta and Active Directory. Keeper grants and revokes privileges directly within your existing infrastructure, so elevation happens where your accounts already live with no disruption to how users authenticate. The identity provider remains your source of truth, while Keeper simply controls when a user is elevated into a privileged group and when they’re removed from it.

That reach is not only for the platforms themselves but also includes applications that federate access and authorization through these identity providers. Federated applications can also use Keeper for access control, allowing users to apply the same JIT model to the downstream apps that teams sign into every day.

Across cloud, databases and machines

Since ZSP isn’t just a cloud-console issue, KeeperPAM applies the same privilege-elevation framework beyond your identity providers. Using PAM Cloud, PAM Database and PAM Machine records, you can extend time-limited access to cloud resources, databases and individual machines, bringing the same lifecycle to the infrastructure behind your identity layer.

Beyond elevation, the Keeper Gateway also rotates privileged credentials so they don’t linger as static targets, and for databases and machines it can provision ephemeral accounts, injecting credentials server-side so the user never handles them. All of it sits within Keeper’s zero-knowledge architecture, meaning credentials and secrets remain end-to-end encrypted and are never exposed to Keeper or anyone else. Together, automated rotation and zero knowledge ensure that even the credentials that enable privileged access don’t persist as materials an attacker could steal and exploit.

Minimize your attack surface with Keeper

Zero standing privilege only works if it’s enforced consistently, which is where Keeper Privileged Cloud thrives. With Keeper, security teams have an auditable way to grant privileged access on demand and revoke it automatically, working through the identity providers and infrastructure you already run. Administrators get provable control over who can access what and when; users get the access they need without waiting for manual provisioning or holding on to rights they don’t.

Request a demo of KeeperPAM to see JIT access and automatic revocation in your environment.

Krowel brings almost 20 years of go-to-market leadership in identity and access management. She spent 14 years at CyberArk, rising through the ranks to Global Vice President of Inside Sales and Chief of Staff to the Go-to-Market (“GTM”)  organization, and most recently served as Vice President of Global Sales Development at Delinea. Grabner brings more than two decades of federal and public sector sales leadership, most recently as Senior Vice President and General Manager at JMA Wireless, with prior leadership roles at Ribbon Communications, Cisco and BroadSoft.

Krowel and Grabner will support and scale Keeper’s GTM teams across key regions to address demand across the midmarket segment, large-scale enterprises and Federal organizations. Last year, Keeper grew its revenue 53.4% in 2025, more than three times the security software market’s overall average of 15.5%, ranking second only to Google in Gartner’s analysis. The $111 billion worldwide security software market grew steadily last year, and Gartner attributed the top performers’ growth in part to platform consolidation and organizations replacing fragmented point solutions with unified platforms.

“The cybersecurity market is seeing an unprecedented inflection point with the advent and widespread adoption of AI technologies,” said Tim Strickland, Chief Revenue Officer of Keeper Security.  “With Jessica and Bill onboard, Keeper is poised to continue accelerating its rocketing growth as organizations seek identity security solutions that harness the power of AI to protect against existing human risks and emerging agentic AI threats.”

Keeper’s flagship identity security platform unifies password and passkey management, privileged session management, secrets management and endpoint privilege management within a single cloud-native, zero-knowledge architecture. The platform incorporates KeeperAI®, which delivers real-time threat detection across privileged sessions, and extends governance to AI agents, machines and non-human identities alongside human users. Both Krowel and Grabner will be responsible for expanding adoption of Keeper in their respective markets, as organizations consolidate fragmented identity tools onto a single solution that provides superior visibility, security and control. 

Keeper’s own 2026 research sheds light on the demand for unified identity security, as only 36% of organizations report having a privileged access management solution fully deployed, and 64% still lack fully consolidated privileged access governance. Most of the market hasn’t solved this problem yet.

“Identity has become the center of enterprise risk and governance given that human and non-human identities are proliferating faster than most organizations can secure and manage them,” said Darren Guccione, CEO and Co-founder of Keeper Security. “We are thrilled to have Jessica and Bill on our team given their superb knowledge and expertise in helping organizations secure and govern all identities in the modern era.”

Why IAM recognition matters

IAM has shifted from a primarily administrative function to an essential security layer that enables modern organizations to govern access across hybrid, multi-cloud and partner ecosystems. The IAM market has expanded drastically to match the fast pace of security advances like AI agents and Non-Human Identities (NHIs), and the vendor landscape has expanded quickly as well. ISG evaluated 20 providers in its 2025 Buyers Guide for IAM, compared with 31 in 2026, including identity governance specialists, privileged access vendors and broader identity platforms. Since IAM decisions now impact nearly every part of the technology stack, choosing the wrong solution can have long-lasting consequences for both organizations and customers if security, governance, scalability, user experience and operational impact aren’t prioritized. A guide like ISG’s is valuable to organizations considering an IAM solution because it applies the same criteria to every provider, uses submitted evidence to support its scoring and publishes the methodology behind its findings.

What “Exemplary” means to ISG

ISG places each evaluated provider into one of four categories based on weighted performance across two dimensions: Product Experience and Customer Experience.

Product Experience, composed of Capability at 50% and Platform at 30%, accounts for 80% of the overall evaluation. Customer Experience represents the remaining 20%, measured through provider validation, Total Cost of Ownership (TCO) and Return on Investment (ROI). Achieving Exemplary status, therefore, requires more than just strong features; Exemplary providers must also demonstrate product strength and the ability to provide measurable value to customers.

Where Keeper stands out in the 2026 ISG Buyers Guide

The 2026 report marks Keeper’s first appearance in the ISG Buyers Guide for IAM, and Keeper debuted at the Exemplary level. Here is how Keeper performed across ISG’s evaluation categories:

Keeper ranked among the top six out of 31 providers for both Product Experience and Customer Experience. Keeper also outperformed several established Privileged Access Management (PAM) providers that ISG evaluated, including CyberArk, Delinea, BeyondTrust and One Identity, in all four categories. These results demonstrate Keeper’s ability to meet – and exceed – critical identity security requirements while maintaining a strong customer experience.

Product Experience

Keeper scored 83.1% on Product Experience, behind only Microsoft, AWS, Okta, Oracle and Google Cloud. This rating reflects Keeper’s growth well beyond credential storage into broader identity and privileged access security. KeeperPAM^® combines privileged session management, credential rotation, enterprise password management, secrets management, connection management, remote browser isolation and endpoint privilege management through a unified, cloud-native platform. As a result, Keeper helps organizations protect human and machine identities, infrastructure secrets and privileged sessions without requiring multiple disconnected tools.

Capability

Capability is the heaviest component in ISG’s evaluation at 50% of the total score, and Keeper scored 85.4% in this category, placing ahead of IBM, SAP, CyberArk, Entrust, ManageEngine, One Identity and BeyondTrust. ISG assesses IAM capabilities across access management and governance, use of AI and machine learning, API and application connector integration, auditing and reporting, identity verification, Multi-Factor Authentication (MFA), Role-Based Access Control (RBAC), self-service functionality and user provisioning. Keeper supports these requirements through capabilities such as enforced MFA, RBAC, delegated administration, Single Sign-On (SSO), SCIM provisioning, automated onboarding and offboarding, granular audit logging with SIEM export and AI-enabled threat detection through KeeperAI^®. Together, these capabilities help organizations enforce access policies, improve visibility and reduce identity-related security risks across complex environments.

Platform

With a score of 81.5% – ranking fourth out of the 31 evaluated providers – Keeper landed within 0.1 percentage point of ISG’s Leader designation. ISG evaluates 16 function points to determine how well a product behaves as part of an organization’s security infrastructure once it’s deployed at scale. Platform specifically covers adaptability, manageability, reliability and usability. ISG named Platform one of Keeper’s two standout areas, citing KeeperPAM’s configurability and its functionality for managing performance and scalability.

This category is where Keeper’s zero-trust, zero-knowledge architecture thrives at enterprise scale. Encryption and decryption happen locally on the user’s device, ensuring that no one – not even Keeper – can ever access customer vault data in plaintext, keeping the attack surface small without asking end users to change how they already work. KeeperPAM also centralizes privileged access across on-premises, hybrid and cloud infrastructure, using the Keeper Gateway to establish secure access to target environments without requiring inbound firewall rules. Combined with FedRAMP High Certification and GovRAMP High Authorization, Keeper supports organizations under strict security and compliance requirements.

Customer Experience

Keeper scored 82.7% for Customer Experience, ranking ahead of Okta, SailPoint, CyberArk and SAP. ISG evaluates this category on provider validation of customer success, TCO and ROI. This part of the evaluation helps buyers look beyond technical functionality and consider what adoption, deployment and long-term use of a platform may look like. For buyers evaluating IAM solutions, a strong Customer Experience score demonstrates that security capabilities are only beneficial when organizations can successfully manage and scale them. ISG specifically rated Keeper’s Customer Experience highly for the support available to help employees and prospective customers calculate TCO and ROI.

What Keeper’s Exemplary recognition means for you

ISG recommends that organizations evaluating IAM solutions prioritize capabilities including unified identity lifecycle management, strong authentication, consistent access governance, adaptive access controls, MFA, auditability, scalability and AI-enabled risk analysis. Keeper’s performance highlights three main considerations for organizations evaluating their identity security strategy:

Enhance your IAM strategy with Keeper

Being named Exemplary in the 2026 ISG Buyers Guide validates Keeper’s approach to modern identity security: combining privileged access, secrets management, endpoint privilege management and enterprise password management within a zero-knowledge architecture. For organizations seeking to reduce complexity while strengthening control over privileged access, KeeperPAM provides a cloud-native platform for protecting sensitive credentials, secrets, infrastructure and privileged sessions. Request a demo of KeeperPAM today to see how Keeper can help improve your organization’s identity security strategy.

Getting there starts with understanding why standing privilege makes up such a significant portion of the cloud attack surface. Staying there takes the right platform to enforce the fix across every cloud and identity you run.

Why standing privileges are your biggest cloud attack surface

Your cloud attack surface is the full set of ways an attacker could get into or act within your environment: every account, credential, permission and integration that touches it. On premises, much of that is network-shaped. In the cloud, it’s identity-shaped. A user, a service account or a connected app with valid credentials and the right permissions doesn’t need to breach a firewall because it’s already inside.

Standing privileges build up quietly. Roles change, projects end and people leave, but the access tends to stay. Over time, that shows up as a few predictable problems:

• Permission creep: Permissions accumulate as roles change and old access requests go unrevoked, leaving accounts with far more than they need.
• Zombie admins: Accounts left active after someone is offboarded or moves roles, still holding privileged access that nobody is watching.
• Shadow admins: Accounts with effective control that don’t look privileged in your directory groups, so standard reviews miss them.
• Machine and Non-Human Identities (NHIs): Service accounts, API keys and workload identities now outnumber human users, and most carry standing permissions of their own.

Each of these is a target. An attacker only needs one compromised credential to get a foothold, and standing privilege is what lets them go further. A single overpermissioned account opens the door to lateral movement and privilege escalation across your environment.

How to eliminate standing privileges

Here’s what to do to start eliminating standing privileges: 

1. Discover and audit privileged access: Inventory every privileged path across AWS, Entra ID, GCP, Okta and Active Directory, covering human users, service accounts and third-party integrations. 
2. Enforce least privilege: Strip away unused and excessive permissions, clean up orphaned and zombie accounts, and surface shadow admins who don’t show up in directory groups.
3. Replace standing admin rights with JIT access: Stop leaving admin rights permanently assigned. Grant privilege on request instead: approved, scoped to a set time window and revoked automatically when the window ends.
4. Target Zero Standing Privilege (ZSP): Least privilege minimizes what each account holds. Zero standing privilege goes further by removing standing access altogether, so no identity retains permanent privileged access and elevation exists only during an approved window.
5. Vault the exceptions: Some credentials still need to exist, like master keys, root accounts and other break-glass access. ZSP doesn’t replace vaulting, so keep those in a vault under strict controls.
6. Make it continuous: Run recurring access reviews and log every elevation so permission creep doesn’t quietly come back.

Something to keep in mind is that standing privilege you clear out of AWS doesn’t help if it’s still sitting in Entra ID or Okta. Enforcement has to cover every cloud and federated identity you run because the gaps you leave become the attack surface you didn’t reduce.

How Keeper Privileged Cloud reduces your cloud attack surface

Keeper Privileged Cloud handles JIT, replacing standing admin rights with elevation granted on request and automatically revoked. It extends KeeperPAM’s just-in-time framework to AWS IAM, Microsoft Entra ID, GCP, Okta and Active Directory, plus any application that federates through them.

Privilege is granted only after approval, for a set duration and removed automatically when the window closes. That’s zero standing privilege in practice: access is approval-based, time-bound and fully auditable, enforced the same way across cloud and federated identity from a single platform.

Shrink your cloud attack surface for good

Few controls reduce your cloud attack surface as much as removing standing privilege, because it removes the always-on access attackers rely on. Keeping it gone is the harder part, and it comes down to ongoing access reviews and automated, time-bound elevation that stop permission creep from rebuilding what you cleared.

To put this in place across every cloud and directory platform you run, start a free trial of KeeperPAM.

Across client environments, this can take many forms:

• A marketing team uses an AI design platform to create campaign visuals
• A sales rep connects an AI assistant to a CRM to summarize customer interactions
• An HR manager uploads a résumé to a public chatbot for evaluation 
• A developer uses an AI coding tool to troubleshoot company source code

And each instance can occur without the MSP ever knowing. 

That doesn’t necessarily mean clients are deliberately withholding information. The issue is that AI use has become highly decentralized in practice. Employees and individual departments can access powerful tools with little more than a browser, credit card or OAuth approval in what is known as shadow AI, allowing new technology to enter an organization before IT teams or service providers are even aware of it, let alone able to fully evaluate it. 

For MSPs, that creates an immediate problem: You can’t effectively protect an environment you can’t see – and you can’t defend what you don’t know exists. 

How shadow AI creates security risks for MSPs

Shadow IT has challenged organizations for years as employees continue to adopt technology outside approved IT channels. Shadow AI, however, escalates the potential exposure. These applications don’t simply sit alongside business systems; they can interact with sensitive company data, connect to existing platforms beyond their initial scope and execute tasks with increasing autonomy. 

Recent research shows just how widespread this behavior has become. KPMG’s 2025 Shadow AI report found that 44% of U.S. employees surveyed knowingly used AI in ways that violated their organization’s policies or guidelines. The motivation isn’t necessarily malicious; it’s often driven by convenience, speed and efficiency. Today’s work culture increasingly rewards those same qualities, encouraging employees to automate repetitive tasks and adopt tools they believe will help them perform better. 

But the drive for greater efficiency doesn’t eliminate risk.

For MSPs, the real concern is what each unrecognized application adds to the environment: another set of connections, permissions and potential access pathways operating outside established oversight. 

The hidden access and permissions behind AI tools 

The security implications of AI use aren’t always obvious to the person adopting the technology. What looks like a simple connection can introduce permissions and access that extend well beyond the immediate task. 

Consider what happens when an employee connects an AI application to a business platform. 

To the user, the process may be as simple as clicking the “Allow” button. Behind that approval can be a series of permissions to retrieve files, access contacts, interact with customer information or connect with other applications.

Those connections can persist beyond the initial interaction, creating access the MSP may not know exists. While the MSP may still manage the endpoint, secure the user’s account and protect the underlying business application, it may not know about the connection sitting between them.

That’s where AI begins to reshape the traditional concept of shadow IT. The unknown is no longer which application is being used. MSPs also need to understand what information an AI service can reach, the exact permissions it has been granted, which credentials support it and whether that access is still necessary.

The consequences of this oversight gap are already emerging. IBM’s 2025 Cost of a Data Breach Report found that 63% of breached organizations surveyed either lacked an AI governance policy or were still developing one. Among those with policies in place, only 34% regularly audited for unsanctioned AI use. Organizations with high levels of shadow AI also incurred breach costs $670,000 higher on average than those with minimal or no unsanctioned AI use. 

Why MSPs need visibility into AI access

For MSPs, the priority isn’t controlling whether clients use AI but understanding how that use changes the environment they’re responsible for securing.

Teams are adopting these applications because they solve real problems and simplify time-consuming tasks. At the organizational level, there are equally strong incentives to explore technologies that enhance productivity.

A more effective response starts by reframing the questions that MSPs ask. 

Documenting which AI applications a client has formally approved is a good starting point, but it only tells part of the story. MSPs need visibility into:

• Which AI services employees are actually using
• Which business applications and data those services can reach
• Which OAuth permissions have been granted
• Which API keys or service accounts enable those connections
• What actions those tools are authorized to take once connected

Most importantly, how far does that access extend, and does it exceed what’s actually required?

These questions shift the discussion from defining policy to assessing practical risk. Even approved AI use can create gaps:

• An AI assistant connected to a CRM may be granted access to customer records beyond what it needs to perform its intended task. 
• The same AI service may be restricted to approved data sources for one department but granted broader access by another.
• Access granted for a temporary project may remain active long after the work ends.

Approval alone doesn’t guarantee appropriate access.

Keeping pace with these changes requires more than a one-time inventory exercise. New applications appear constantly, existing SaaS vendors continue to add AI capabilities while autonomous agents perform tasks that, until recently, required direct human involvement. Monitoring this activity should be standard practice in MSP security reviews and ongoing client conversations. 

The industry’s growing focus on AI discovery reflects the urgency of that need. Dedicated security capabilities are increasingly emerging to identify generative AI applications used without IT approval, analyze usage patterns, assess application risk and monitor potential data exposure. For smaller organizations without comparable resources in-house, this creates an area where MSPs can provide valuable visibility and guidance. AI discovery is quickly becoming an essential part of maintaining visibility across client environments. 

Administrators can review usage patterns, identify unsanctioned applications, assess application risk, evaluate access permissions and monitor potential data exposure. These capabilities can reveal AI activity that might otherwise remain outside traditional IT oversight.

For MSPs, AI discovery is quickly becoming an essential part of maintaining visibility across client environments. 

How MSPs can improve AI governance with clients

For most organizations, closing this gap isn’t simply a technical challenge; it’s a communication challenge.

The disconnect often widens when employees don’t recognize which AI-related decisions carry security implications or warrant MSP involvement. What may initially appear to be a simple application, integration or departmental purchase can introduce new permissions, credentials and access requirements that extend well beyond its intended use. 

For MSPs, stronger AI governance starts with setting clear expectations around when and how clients communicate AI-related changes. Those conversations should address questions such as: 

• Which new AI tools are teams experimenting with, and are they approved for business use?
• Have any departments connected AI tools directly to sensitive systems or business-critical applications?
• What company, customer or other sensitive data is being shared with these tools, and where does that data go once submitted?
• Who owns each AI integration and is responsible for managing its access over time?
• Have permissions expanded or changed since the tool was introduced?
• Are previously approved integrations still necessary, or does access remain after the original business need has ended? 

By initiating these discussions and keeping them active as client environments change, MSPs can surface AI activity before it adds another unmanaged layer to the environment. More importantly, MSPs can enable clients to move quickly with AI without letting access, permissions and oversight fall behind.

The goal is simple: MSPs need real-time visibility into AI deployments before those tools access company data or systems.

How MSPs can secure AI access across client environments

Discovering previously unknown AI use solves only part of the problem. Once that activity comes into view, MSPs need a consistent way to bring it under control across every client environment. 

AI assistants, integrations and agents ultimately depend on credentials, permissions and connections to business systems. Those pathways must be protected, privileges limited to what’s necessary and permissions adjusted as requirements change. For MSPs operating at scale, the challenge is applying those principles consistently across multiple clients as their environments evolve. 

Keeper provides MSPs with a unified platform to do exactly that. By consolidating credential security, privileged access, secrets management and endpoint privilege management within a zero-trust, zero-knowledge architecture, Keeper helps MSPs govern human and machine identities at scale without introducing another disconnected layer into the security stack. 

The most consequential AI risk may not come from the applications an MSP already manages. 

It may come from the ones no one thought to mention.

Discover the Keeper MSP Partner Program and see how Keeper equips MSPs to close AI visibility gaps across client environments.

This blog covers the importance of zero standing privilege, how the Keeper Privileged Cloud workflow works and which platforms Keeper Privileged Cloud supports.

Why zero standing privilege matters

Every permanent admin privilege increases your attack surface, whether or not it’s being used. Permissions accumulate through privilege creep, old admin access stays active long after anyone needs it and each unused privilege widens the blast radius when credentials are stolen. The more standing access an organization holds, the more permissions an attacker inherits the moment they gain access.

Zero standing privilege takes that exposure away. No identity holds permanent privileged access. An account is elevated only during an approved, time-limited window; once the window ends, the access is gone, so nothing sits idle for an attacker to find or abuse.

JIT access is what makes ZSP practical. JIT grants permissions when someone needs them and revokes them afterward, instead of assigning them permanently. The two aren’t interchangeable: JIT controls when access is granted, while ZSP means there’s no standing privilege remaining once a user’s task is complete.

How Keeper Privileged Cloud enforces zero standing privilege

Keeper Privileged Cloud enforces zero standing privilege with a request-and-approval workflow: a user requests access to a specific resource, an approver signs off, Keeper elevates the user for a set time window and it removes that access automatically when the window ends.

Keeper Privileged Cloud is part of KeeperPAM, Keeper’s identity security platform, and applies the same JIT framework to your cloud Identity Providers (IdPs). It works with three record types: PAM Cloud Resource, PAM Machine and PAM Database. Each record requires two configurations before anyone can request access: JIT settings, which define how access is granted, and Workflow settings, which define the approval requirements, time limit, reason and ticket number.

A few prerequisites need to be in place first: a configured Keeper Secrets Manager application, a deployed KeeperPAM Gateway, Workflow-based access enabled and a PAM Configuration for a supported IdP. The Gateway is a lightweight service you run on your own network using Docker on Linux or Windows, providing outbound access to your target infrastructure.

Once that’s set up, the workflow runs like this:

If a request is denied, the record reverts to “Request Access,” and the user can resubmit.

Elevation happens at the group or role level, either at the IdP or directly on the resource. Keeper Privileged Cloud covers the IdPs most organizations already use: AWS IAM, Microsoft Entra ID, Google Cloud Platform, Okta and Active Directory, along with any application that federates through them. Keeper handles those identities directly on the resource or through a federated provider.

After access is approved, there are two ways to get to the resource. One is Keeper’s Remote Browser Isolation, launched from the Keeper Vault. The other is a standard login through the AWS portal, Command-Line Interface (CLI) or Terraform.

What Keeper Privileged Cloud gives security teams

With that workflow running through Keeper Privileged Cloud, security teams have less privileged access to defend and a clear audit trail for granted access.

A smaller attack surface

There’s no dormant privilege for an attacker to find between tasks. Because every elevation is temporary, the privileged attack surface only exists while access is in use.

Access that is approval-based, time-bound and auditable

Every elevation is requested, approved and recorded. That gives security teams a log of who requested access, who approved it and when it expired. This audit trail supports access control evidence requirements under frameworks like SOC 2, CMMC and NIST 800-53, in addition to routine internal reviews.

Consistent enforcement from one platform

The same workflow runs across every cloud and federated IdP you connect, so you aren’t managing a separate set of controls for AWS, Entra ID and Okta.

Eliminate standing privilege with Keeper

With Keeper Privileged Cloud, privileged access exists only after someone requests it, has it approved and uses it within a set window. Once the window closes, there’s nothing left to secure or steal.

To see how Keeper Privileged Cloud works against your cloud and identity setup, request a KeeperPAM demo.

Continue reading to learn the most common zero standing privilege challenges, how to approach them and the ways Keeper^® can help.

6 most common zero standing privilege challenges

While having zero standing privilege is desirable for every organization, it isn’t always easy to achieve it. Here are some of the most common ZSP challenges and how to work through each one.

1. Legacy systems

Older infrastructure and applications were built to run on persistent credentials to have a login that’s always available. This is the opposite of what ZSP requires, so these systems often can’t natively grant access on the fly and revoke it soon after, making them one of the hardest places to apply the model. The solution is to migrate in phases rather than all at once, starting with the highest-risk systems first and putting a Privileged Access Management (PAM) proxy in front of the legacy system. With the proxy acting as a gatekeeper, the old system keeps working the only way it knows how, while the PAM tool brokers temporary access and logs everything.

2. Non-Human Identities (NHIs)

Standing privileges aren’t only a human problem; they also apply to Non-Human Identities (NHIs). Service accounts and automations frequently carry long-lived credentials that were set up once and then forgotten because a human doesn’t actually use them, so no one rotates and revokes them. Since these identities often have privileged access and, in cloud-native environments, outnumber human users approximately 144:1, they’re a growing and frequently overlooked part of attack surfaces. Organizations must govern NHIs with the same rigor they apply to people: Replace long-lived credentials with short-lived ones issued at runtime that expire automatically, so no standing access is waiting to be stolen.

3. Agentic AI

In addition to machine identities, AI agents introduce another obstacle when enforcing zero standing privilege. They’re ephemeral, designed to handle a task and function with what they need to access at runtime. If organizations try to provision their access ahead of time, they end up overprovisioning just in case, and that access accumulates and drifts out of scope. Granting AI agents access only at runtime is necessary, as well as scoping each token tightly to the specific task or tool the agent is using and having that access expire as soon as the task is completed.

4. RBAC complexity

Role-Based Access Control (RBAC) is a natural foundation for zero standing privilege, but defining precise, task-level roles at scale is difficult. Roles change as people take on new responsibilities, permissions accumulate over time and eventually your carefully designed roles no longer reflect the privileged access your organization needs. The solution is to maintain role accuracy with regular access reviews and automated entitlement discovery to identify unused access and move toward Attribute-Based Access Control (ABAC).

5. Resistance and productivity friction

People tend to treat standing access as something they own, which is why asking them to give it up results in resistance and a fear that request-and-approve workflows will slow fast-paced teams. Left unaddressed, that pushback stalls rollouts before they get traction. The solution centers on communication by explaining why the change matters and using real breach examples driven by standing access to make the risk tangible rather than abstract.

6. Auditability gaps

It’s very difficult to prove ZSP is actually working without having real-time visibility into who accessed what, when and why. If organizations can’t demonstrate that access is being granted and revoked properly, they can’t satisfy auditors or, frankly, trust the model themselves. To combat this, organizations must have centralized logging, session monitoring and recording and continuous access reviews that produce records they can hand directly to auditors. Provable visibility is what turns ZSP from a policy on paper into something you can actually verify.

How to approach zero standing privilege challenges

Although many ZSP challenges are real, they’re solvable with the right solutions. Here are steps to achieving zero standing privilege in your organization:

Overcome zero standing privilege challenges with Keeper

Having the right sequencing and automation to handle access shifts zero standing privilege from appearing intimidating to being manageable. Keeper Privileged Cloud enforces ZSP by granting elevated access only when it’s requested, approved and needed — then automatically revoking it when the approved window ends. Keeper works across your existing identity providers, including AWS, Microsoft Entra ID, Google Cloud, Okta and Active Directory. It also keeps a full audit trail of who requested access, who approved it and when it expired. The combination of automated elevation and full visibility addresses some of the toughest ZSP challenges, all without introducing another disconnected system to maintain.

Request a demo of KeeperPAM to eliminate standing privileges across your organization.

Continue reading to learn more about each model, their key differences and why organizations should implement both.

What is zero standing privilege?

Zero Standing Privilege (ZSP) eliminates standing privileged access for every identity – both human and machine – in an organization. Under ZSP, no identity holds privileged access by default; instead, users request temporary access for each task, and those privileges are automatically revoked once the task is completed. The goal of ZSP is for no account to have standing access that an attacker could exploit.

ZSP works by evaluating each access request at runtime rather than provisioning access in advance. When a user requests access, policy evaluates the request in real time, determining whether the requested access is appropriate based on who is making the request, what access is being requested and the applicable conditions. If it is, only the minimum task-specific privileges are granted, and that access expires as soon as the task is complete. This ensures privileges exist only for the brief period they’re actually in use. 

Achieving ZSP matters because standing access is one of the most persistent attack surfaces in any environment. Permanent access rights tend to accumulate over time in what is known as privilege creep. If an attacker compromises an account with permanent access, they can move laterally through a network and escalate their access to cause widespread damage. By granting privileges only when necessary and for as long as needed, ZSP significantly narrows that window and limits the blast radius of any single compromised credential.

What is the Principle of Least Privilege (PoLP)?

The Principle of Least Privilege (PoLP) is a concept in which every identity is granted only the minimum access necessary to perform its job – nothing more. Implementing least privilege applies not only to people but also to applications, devices and systems. By limiting each identity to only the data and systems it actually needs, least privilege restricts what a user can reach and prevents unauthorized changes. Least privilege is a fundamental control for minimizing the attack surface, reducing insider threats and limiting lateral movement if an account is ever compromised.

The limitation is that least privilege scopes only how much access an identity has, not necessarily how long it keeps that access. Permissions are typically assigned based on a role and then left in place, so when a task is completed, that access may linger rather than being pulled back. The result is standing access: privileges that persist indefinitely even though they’re no longer necessary. Even a perfectly scoped least-privilege setup can leave a permanent attack surface, which is exactly why ZSP is important for closing that gap.

The key differences between zero standing privilege and least privilege

One of the key differences between ZSP and least privilege comes down to scope versus time. Simply put, least privilege limits how much access you have, while ZSP limits how much access you have and how long you have it. That makes ZSP the natural evolution of least privilege, taking the same goal of reducing risk and extending it across time. Here are the ways ZSP and least privilege compare.

How zero standing privilege and least privilege work together

Zero standing privilege and least privilege are designed to work together, with least privilege serving as the foundation for ZSP. Organizations can’t meaningfully eliminate standing access without first knowing what the minimum necessary access looks like for each identity. Least privilege tells organizations how much access a user should ever have, and ZSP ensures that users have that access only for a temporary period of time. A good way to think about this is that ZSP is the product of least privilege, Just-in-Time (JIT) access and automatic revocation. Least privilege defines the minimum scope, JIT access grants that access in real time and automatic revocation ensures nothing lingers as a standing privilege. Combining the three results in zero standing privilege: the right amount of access, granted only when necessary and revoked as soon as it is no longer needed.

How to implement zero standing privilege

Moving toward ZSP is a gradual process for most organizations. Since least privilege is what ZSP is built on, many teams achieve ZSP by tightening the access scope first, then removing the remaining standing access. Here’s how to approach ZSP:

Enforce zero standing privilege with Keeper

ZSP and least privilege work best when combined in the same strategy. Enforcing ZSP means enforcing least privilege as a baseline, layering JIT access with automatic expiration and extending those controls across all identities. A cloud-native, zero-knowledge identity security solution like KeeperPAM^® helps organizations enforce least privilege and work toward ZSP through RBAC, JIT access and advanced auditing in a unified platform. By granting access only when needed and automatically revoking it, KeeperPAM narrows your attack surface to the narrow window of active use, helping prevent standing privileges from becoming a liability.

Request a demo of KeeperPAM to see how it enforces least privilege and ZSP across your organization.

As organizations scale workflow automation across cloud environments, secrets management has become a critical, and frequently overlooked, gap. Hardcoded credentials in automation scripts and workflows represent one of the most persistent and exploitable vulnerabilities in enterprise environments. The Keeper Secrets Manager connector for Azure Logic Apps addresses this directly, giving teams a zero-knowledge, policy-enforced path to secrets management inside Microsoft Power Platform.

“Workflow automation is only as secure as the secrets powering it, and most organizations are still hardcoding those secrets which creates massive cyber risk,” said Darren Guccione, CEO and Co-founder of Keeper Security. “This connector eliminates that exposure by bringing Keeper’s zero-knowledge architecture directly into the Microsoft automation layer: secrets stay encrypted in the vault and are retrieved only at the moment they are needed, so there is nothing hardcoded to steal.”

The connector operates through a lightweight Python middleware service deployed as an Azure Function App, communicating with the Keeper Vault via the Keeper Secrets Manager SDK. All secrets remain encrypted under Keeper’s zero-knowledge security architecture and are decrypted locally within the customer’s Azure environment – never transmitted in plaintext through Keeper’s infrastructure. 

“The architecture here reflects a principle Keeper holds across the entire platform,” said Craig Lurey, CTO and Co-founder of Keeper Security. “Secrets should be decrypted as close to the workload as possible and only when needed. The Azure Function middleware gives customers a deployment model where the Keeper SDK runs inside their own Azure environment, their own key management handles the configuration and plaintext credentials are never in motion across a network boundary they do not control.”

Key capabilities of the Keeper Secrets Manager Connector for Azure Logic Apps

• Certified connector: Integrates natively in the Logic App Designer with no custom import required for standard deployments.
• Runtime secrets retrieval: Fetches credentials on demand within any Logic App flow without storing them in the workflow definition.
• One-click deployment: Provisions all required infrastructure – including the Azure Function App, Key Vault and Managed Identity – in minutes using an Azure Resource Manager (ARM) template.
• Dynamic dropdowns: Auto-populates secret and folder pickers in the Logic App designer, reducing configuration error and accelerating deployment.
• Credential creation: Provisions secrets directly from automated workflows, supporting employee onboarding and scheduled compliance audits.

The connector supports five operations, including List Secrets, Get Secret, Create Secret, Update Secret and List Folders, covering workflows from API credential injection and database connection string retrieval to GitHub secret synchronization and vault compliance auditing.

The Keeper Secrets Manager connector for Azure Logic Apps is available now. Full documentation, the middleware repository and deployment instructions are available at docs.keeper.io.

The threat window is growing

The education sector is one of the highest targeted industries for ransomware, credential theft and data breaches. Schools and universities present an appealing combination of high-value data, including student records, financial information and research, alongside chronically underfunded IT departments and an enormous, ever-rotating user base.

Back-to-school season intensifies every one of these vulnerabilities. Bulk account creation, mass device enrollment and a surge of third-party application onboarding all happen simultaneously, creating a window of misconfiguration and exposure that attackers are primed to exploit. However, Keeper research finds only 14% of schools mandate security awareness training, and that lack of education shows, with nearly one in five students and parents reporting they reuse the same passwords across both personal and school accounts.

AI has made cybersecurity threats significantly more dangerous. Phishing emails can now precisely mimic communications from financial aid offices, IT helpdesks or university leadership, with none of the red flags that once made them easy to spot. Deepfake voice and video attacks are putting convincing faces and voices behind those messages, making it harder for staff to trust what they see and hear. Keeper research found 52% of education leaders identify deepfake impersonation as a top concern, yet only 26% feel confident in their ability to recognize AI-enabled threats. And the barrier to entry for attackers has dropped dramatically: tools that once required real sophistication are now widely available, meaning credential attacks that previously targeted only the largest institutions can now be aimed at any school district or campus. Forty-one percent of institutions report that they have been targeted by AI-generated phishing attempts or misinformation campaigns.

The hidden attack surface: Non-human identities in EdTech

While IT teams focus on securing human accounts, a far larger and largely invisible population of digital identities is growing unchecked across education environments: Non-Human Identities (NHIs). In a modern school district or university, NHIs are widespread and almost entirely unmanaged:

• Service accounts synchronize student rosters and course enrollments between Student Information Systems like PowerSchool or Banner, and Learning Management Systems like Canvas, Blackboard or Google Classroom. Their credentials are rarely rotated, often shared and almost never audited.
• API keys and integration tokens connect third-party learning applications, digital textbooks, library databases and payment gateways to central institutional databases. Orphaned tokens from prior-year integrations frequently remain active.
• Machine identities and digital certificates authenticate campus-wide Wi-Fi connections, interactive smart boards, lab equipment, 3D printers and security cameras. Expired or misconfigured certificates create silent gaps in network security.
• Cloud-managed identities and workloads on platforms like Azure, AWS and Google Cloud manage automated data backups, research data pipelines and administrative reporting, often with far broader permissions than their tasks require.
• AI agents and automated bots powering admissions chatbots, helpdesk scripts and grading assistants each carry their own identity and access rights, and are among the fastest-growing and least-governed NHIs in education today.

In most institutions, NHIs outnumber human users by a wide margin, yet few schools maintain an inventory of them. This causes the attack surface to explode, as each NHI represents a potential entry point for attackers.

“The conversation about education cybersecurity has historically focused on human accounts: students, teachers and administrators,” said Darren Guccione, CEO and Co-founder of Keeper Security. “But the real blind spot is the vast ecosystem of machine identities that power modern EdTech. Back-to-school is the right moment for education IT teams to take stock of every identity on their network, human and non-human alike.”

How education IT teams can reduce their risk

For most institutions, the fundamentals are manageable: enforcing MFA, auditing privileged access and removing stale credentials before new users arrive. The harder challenge is building visibility and governance over the NHIs that power modern EdTech: service accounts, API tokens, machine certificates and AI agents that multiply with every new integration. Keeper recommends education IT teams take the following steps before the semester begins:

• Enforce MFA across all faculty, staff and student accounts before new users are onboarded. It remains the single most effective control against credential-based attacks.
• Deploy an enterprise password manager institution-wide to eliminate weak, reused and shared passwords. Ensure all privileged accounts are covered.
• Audit privileged access, both human and non-human, before the semester starts. Remove access for departed employees, expired service accounts and applications no longer in use.
• Build a non-human identity inventory. Catalog every service account, API key, machine certificate, cloud identity and AI agent in your environment. You cannot secure what you cannot see.
• Establish credential rotation policies for machine identities, with particular attention to AI agents and third-party EdTech integrations added for the new school year. Automate rotation wherever possible.
• Update phishing awareness training to reflect the reality that AI-generated messages may now be indistinguishable from legitimate institutional communications.

Keeper’s zero-trust, zero-knowledge platform is purpose-built for these challenges, enabling institutions to discover, govern and automatically rotate credentials tied to human users and NHIs, including the AI agents and automated bots proliferating across EdTech environments. KeeperPAM also delivers the privileged access controls, session recording and audit trails institutions need to meet Family Educational Rights and Privacy Act (FERPA) and Children’s Internet Protection Act (CIPA) requirements, and to ensure every identity on the network, human or non-human, is accounted for.