Netwrix’s 2026 research identified a fourfold difference in breach rates between organizations where AI has substantially expanded the number of identities and those where identity volumes have remained largely unchanged. Static credentials provide AI with one of the simplest paths into an environment. These include passwords, keys, and tokens that remain valid indefinitely and may go unchecked for long periods.
AI did not create the problem of excessive privileges. Instead, it made it possible to exploit over-privileged credentials more quickly and efficiently. Every agent, script, and integration operating within an environment must authenticate using some form of identity. In many environments, that authentication still depends on a password, API key, or token that was issued once and has never been revisited. A forgotten human password may eventually lead to a failed login or account lockout. A machine identity, however, can continue using the same credential indefinitely unless its activity is actively monitored.
More identities, more breaches
A survey of 2,317 security and IT leaders conducted this year produced one particularly clear finding. Organizations in which AI has significantly increased the number of identities reported a 43% breach rate during the previous 12 months. Among organizations where AI had little impact on identity counts, the corresponding figure was 11%. That represents an approximately fourfold difference. The gap cannot be explained simply by weaker overall security among organizations with heavier AI adoption. The research indicates that these organizations were actually more advanced in most fundamental security practices.
The area where this advantage did not extend was governance. Seventy-six percent of surveyed organizations reported that their non-human identities are not fully governed or monitored. Only 19% stated that they have complete governance in place. This is precisely the identity population through which AI operates: an expanding collection of machine identities, many of which rely on credentials that have not been reviewed since they were originally issued.
Static credentials
A static credential does not automatically expire, rotate, or react to repeated use. These characteristics become especially dangerous when such credentials are embedded in automated processes. Misuse of a stolen human password is likely to attract attention eventually. By contrast, an AI agent or automated script operating with a compromised credential can continue executing at the speed permitted by the workflow until the activity is discovered.
Steps to secure NHI credentials
1. Vaulting
The first step is to remove credentials from scripts, configuration files, spreadsheets, and source code and place them in a system specifically designed for secure storage. Although the principle sounds straightforward, implementation is rarely simple. A must support both strategic and legacy applications. It also needs to accommodate different access mechanisms because applications may interact with credentials in different ways. In addition, the system should allow centralized credential onboarding while recognizing that some teams will still need to add credentials manually.
In practice, this often requires a multi-tier architecture. A presentation layer provides the user interface. An application server applies business logic and permissions. A database layer stores the actual secrets. Multiple application servers can also be deployed when load must be distributed across geographically dispersed teams. Vaulting usually delivers benefits quickly because it transforms a credential from something that may be easily discovered into an asset whose storage and use are centrally controlled.
2. Encryption
After a credential has been placed in a vault, it must remain encrypted. The encryption keys require the same level of protection as the credentials themselves. Effective protection therefore involves much more than simply enabling AES.
A properly designed vault should use authenticated encryption, such as AES-GCM 256, to protect stored credentials. Strong key-derivation functions with high iteration counts should be applied to user and key hashing. Elliptic-curve cryptography should be used for public-private key exchange. Each secret container should have an independently generated random salt. Every password, user, and role should also have its own key pair. This creates a hierarchical encryption model instead of relying on a single shared key for access control.
For environments integrated with Active Directory, the strongest configuration should include an end-to-end encryption mode in which the server never receives access to plaintext credentials. A master-key mode should also remain available for organizations that require centralized recovery capabilities. The master key itself should not be stored in a configuration file. It belongs in dedicated hardware and should be protected by a hardware security module (HSM).
Moving a password from plaintext storage into an encrypted vault built according to these principles is one of the most common ways to reduce credential-related risk. It is also one of the most achievable starting points for organizations that have not yet introduced comprehensive non-human identity security.
3. Cycling and rotation
Regular credential rotation helps reduce risks associated with former employees, removes lingering credential exposure from old code and scripts, and can reveal previously unknown dependencies. At the same time, rotation is often the most difficult control to implement correctly. When every script and integration depending on a credential is not known, changing that credential can disrupt production rather than reduce risk.
For rotation to be effective, it must operate as a continuous and automated process that is tightly integrated with the vault holding the credential. It should not depend on someone remembering to perform a manual task. This requires trigger-based resets rather than calendar reminders. A credential can be reset a defined number of minutes after being viewed, after remaining unchanged for a specified number of days, or after reaching expiration.
The rotation process must also protect against its own failures. If an automated reset fails midway for an Active Directory account, a Windows or Linux local user, or a service account, the system should automatically restore the previous known-good credential. The failure should also be logged. This prevents a service account from being left in an inconsistent, partially changed state.
Every reset, rollback, and block should be recorded. As a result, an unsuccessful rotation becomes visible immediately instead of emerging weeks later as an unexplained outage.
Organizations that make meaningful progress in this area generally establish vaulting and encryption first. Automated, trigger-based rotation can then be introduced once credential dependencies are understood well enough to configure the process safely.
Meet Password Secure
Every service account and application account connected to Active Directory is subject to the same policy engine that governs employee accounts, regardless of whether those policies are being actively enforced. Netwrix Password Secure directly addresses all three stages described above.
The product provides a centralized encrypted vault for user, administrator, and service credentials. Each secret is protected using FIPS-compliant cryptography, including AES-GCM 256, PBKDF2-hardened key derivation, and NIST P-521 elliptic-curve key exchange. Role-based access controls ensure that only authorized people and processes can retrieve a credential. A complete logbook records every checkout, reset, and rollback. This makes it possible to determine who accessed a specific credential and when that access occurred.
Configurable, trigger-based Password Reset functionality addresses credential rotation. Credentials can be reset automatically according to a schedule or when a predefined condition is met. Rollback protection is available when the target system rejects a credential change.
The result is a fundamental difference in how service account passwords are handled. Instead of remaining indefinitely in a spreadsheet and never being rotated because of concerns about breaking dependent systems, the credential can be stored in an encrypted vault, protected by access controls, fully logged, and rotated according to a schedule defined by the organization.
