Reversible encryption is a password storage setting that allows credentials to be recovered in plaintext-equivalent form for compatibility with older applications. It exists to support legacy authentication needs, but it materially increases exposure if the encrypted value is compromised. Security teams should disable it unless a documented business requirement truly depends on it.
What reversible encryption means
Reversible encryption is not a general encryption pattern, it is a password storage choice that preserves recoverability so legacy systems can still retrieve the original value when they need to. That compatibility comes at a cost: if the protected store or the decryption path is exposed, the credential can be recovered rather than merely checked.
Because the setting is tied to authentication design, it is best understood as a compatibility exception rather than a normal password-handling mode. The core question is whether the business truly needs plaintext-equivalent recovery, or whether the application can be modernised to use a one-way password verifier instead.
Why it is used in legacy environments
Older applications sometimes depend on being able to recover a user secret exactly as it was stored, usually because the design predates modern password hashing expectations or because an integrated workflow still expects the credential in recoverable form. In those cases, reversible encryption is used to preserve function while a migration path is planned.
That design is usually a sign of technical debt, not a preferred state. Where older software is involved, the important distinction is between compatibility and necessity, because many teams leave the setting enabled long after the original dependency has disappeared.
How it changes the security model
Hashing and reversible encryption answer different questions. A hash lets a system verify a secret without retaining the secret itself, while reversible encryption keeps a decryptable form that depends on the protection of the encryption key and the surrounding access controls. If an attacker obtains both the encrypted value and the means to decrypt it, they gain the original credential material.
That makes the control boundary much broader than many teams expect. Protection depends not only on the storage location, but also on key custody, privileged access to the decryption routine, backup handling, logging hygiene, and any application or administrator path that can retrieve the value.
When to disable it and what to verify
In practice, reversible encryption should be treated as an exception that requires a documented business justification and a clear retirement plan. Encryption Guide is a useful reference for the wider encryption trade-offs that sit behind that decision, especially where key custody and plaintext exposure matter. Encryption Buyer's Guide adds the vendor and key-management perspective that helps teams decide whether a legacy compatibility requirement is actually worth carrying forward.
Teams should verify where the setting is enabled, who can decrypt the stored value, and whether any downstream system still truly needs recoverable credentials. If not, the safer design is to remove the dependency and move to a one-way password storage approach.
Risk and Threat Considerations
Reversible encryption materially increases the blast radius of a storage compromise because the protected value is still recoverable in credential form. That makes it attractive to attackers who gain access to application data, backups, configuration stores, or decryption paths.
Failure mechanism: An attacker or insider obtains the encrypted password store and then abuses a weakly protected key, service account, application routine, or administrative path to recover the plaintext-equivalent secret.
Impact: The exposed credential can be reused for account takeover, lateral movement, or access to other systems that trust the same password or reused secret.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Reversible password storage affects authenticator lifecycle and protection. |
| IA-9 — Service Identification and Authentication | Recoverable credentials can undermine service-to-service authentication paths. | |
| AC-6 — Least Privilege | Decryption paths must be restricted because recoverable secrets expand privileged access exposure. | |
| Recommendation — Use IA-5 to eliminate reversible password handling and manage authenticators through stronger storage and rotation controls. Use IA-9 to ensure service credentials are not stored in recoverable form where interoperability creates risk. Apply AC-6 to limit who can retrieve or decrypt any recoverable credential material. | ||
| CIS Controls v8 | 5 — Account Management | Legacy password recovery settings often persist because account and authenticator lifecycle is not retired. |
| Recommendation — Remove reversible password storage as part of account and authenticator lifecycle management. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Recoverable passwords require tighter access control around decryption and storage paths. |
| Recommendation — Restrict access to any reversible credential store and its decrypt capability under A.5.15. | ||
Practitioner Guidance
Why practitioners should care: The setting is usually not a security control, it is a legacy compatibility choice that should be removed when possible. Keep an explicit inventory of every place it is enabled so the exception does not survive unnoticed after the original dependency has gone.
Common misunderstanding: Teams sometimes assume “encrypted” automatically means safe for password storage. With reversible encryption, confidentiality depends on the full decryption path, so the real question is whether anyone or anything can still recover the original secret.
Practitioner takeaway: If the business case is vague, temporary, or undocumented, treat the setting as a migration issue, not an acceptable steady state.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org