Static credentials are still AI's easiest way in

AI didn't invent the over-privileged credential, it just found the fastest way to use one. Every agent, script, and integration running in your environment authenticates with something, and in most environments, that something is a password, an API key, or a token issued once and never touched again. A person forgets a password and gets locked out eventually. A machine identity just keeps using what it was given, for as long as nobody's watching.

More identities, more breaches

We surveyed 2,317 security and IT leaders this year, and the clearest number in the results was this: organizations where AI has significantly increased the number of identities in their environment reported a 43% breach rate over the past 12 months. Organizations where AI hasn't changed their identity count much reported 11%. That's a 4x difference, and it isn't because the AI-heavy group had weaker security overall. Our data shows they were ahead on most of the basics.

Where they weren't ahead was non-human identity governance. Seventy-six percent of organizations told us they don't fully govern or monitor their non-human identities, and only 19% said they do. That's the population AI is running through: a growing set of machine identities, most of them authenticating with a credential nobody's checked since the day it was issued.

Static credentials

A static credential doesn't expire on its own, doesn't rotate on its own, and doesn't care how many times it gets used. That's what makes it dangerous once it's sitting inside something automated. A person using a stolen password gets noticed eventually. An AI agent or script using a stolen credential just keeps running, at whatever speed the workflow allows, until someone finds it.

Steps to secure NHI credentials

1. Vaulting

The first move is getting credentials out of scripts, config files, spreadsheets, and source code and into a system built to store them. This sounds simple and rarely is. A vault has to work across strategic and legacy applications, cover different access patterns depending on how each app talks to a credential, and support both centralized onboarding and the reality that some teams will always add credentials manually. In practice, this means a multi-tier architecture: a presentation layer for users, an application server that enforces business logic and permissions, and a database layer that actually stores the secrets, with the option to scale out multiple application servers to distribute load across geographically distributed teams. Vaulting is also the step that pays off fastest, since it's the difference between a credential anyone can find and one that's actually controlled.

2. Encryption

Once a credential is in a vault, it needs to stay encrypted, with the encryption keys managed just as carefully as the credentials themselves. That means more than flipping on AES and calling it done. A properly built vault should use authenticated encryption (AES-GCM 256) for the credentials themselves, strong key-derivation functions with high iteration counts for user and key hashing, and elliptic-curve cryptography for public-private key exchange. Every secret container should carry its own randomly generated salt, and every password, user, and role should have its own key pair, so access is hierarchically encrypted rather than gated by a single shared key. For environments syncing with Active Directory, an end-to-end encryption mode, where the server itself never has access to plaintext, should be available as the strongest option, alongside a master-key mode for organizations that need centralized recovery. The master key itself belongs in hardware, not in a config file, protected by an HSM. Moving a password from plain text to an encrypted vault built this way is the single most common way organizations reduce credential risk, and it's the step most within reach for teams that haven't tackled NHI security before.

3. Cycling and rotation

Rotating credentials regularly cuts risk around departed employees, cleans up exposure sitting in old code and scripts, and often surfaces dependencies nobody knew existed. It's also the hardest step to execute. If you don't know every script and integration that relies on a given credential, rotating it can break production instead of reducing risk.

Rotation only works as an ongoing, automated process tied tightly to whatever vault is holding the credential, not a manual task someone remembers to do. That means trigger-based resets, not calendar reminders: reset a credential a set number of minutes after it's been viewed, after it's gone unchanged for a defined number of days, or once it's expired. It also means the process has to protect itself. If a scripted reset fails partway through, on an Active Directory account, a Windows or Linux local user, or a service account, the system should roll the credential back to its last known-good value automatically and log the failure, rather than leaving a service account in a broken half-changed state. Every reset, rollback, and block gets recorded, so a failed rotation is visible immediately instead of surfacing three weeks later as an outage nobody can explain.

Most organizations that make real progress nail vaulting and encryption first, then build toward automated, trigger-based rotation once they understand their dependencies well enough to configure it safely.

Meet Password Secure

Every service account and application account tied to Active Directory runs through the same policy engine as your employees, whether anyone's enforcing it or not. Netwrix Password Secure covers all three steps directly.

It gives you a single encrypted vault for user, admin, and service credentials, with FIPS-compliant cryptography (AES-GCM 256, PBKDF2-hardened key derivation, and NIST P-521 elliptic curve key exchange) protecting every secret. Role-based access means only the people and processes that need a credential can retrieve it, and a full logbook records every checkout, reset, and rollback, so you can answer who touched a given credential and when. On top of that, configurable, trigger-based Password Reset handles the rotation piece: credentials reset automatically on a schedule or on a defined condition, with rollback protection if a target system rejects the change.

That's the gap between a service account password living in a spreadsheet indefinitely, never rotated because nobody wants to risk breaking something, and living somewhere it's encrypted, access-controlled, logged, and rotated on a schedule the organization actually controls.