An encrypted JSON export protects all password entries with encryption, so the file is not readable without the correct account key or password. A standard CSV export is plain text and can be read by anyone who accesses it. That makes encrypted JSON the safer choice for portability, while CSV is mainly useful when human readability or manual processing matters.
Why the file format changes the exposure model
An encrypted JSON vault export and a standard CSV export may both contain the same stored entries, but they do not create the same risk. The key difference is whether the export is still protected as a secret-bearing file at rest, or whether it becomes immediately readable text once copied, synced, or emailed. That changes how you handle storage, sharing, backup, and incident response.
Encryption preserves confidentiality only if the account key or password remains protected, so the file is still sensitive even when it is “just a backup.” CSV, by contrast, is easy to inspect and import, but that convenience also makes it far easier to expose credentials if the file lands in the wrong place.
When practitioners evaluate export formats, they should treat the export artifact itself as part of the security boundary. A safer format reduces the chance that a routine operational task becomes a secrets exposure event, especially when exports are moved between tools, people, or environments.
Encrypted exports are consistent with the broader guidance to protect secrets as high-value material and to reduce exposure from misconfigured vaults or uncontrolled copies. That is why controls around vaulting, credential hygiene, and rotation matter even after the export is created, not just while the data sits in the source system. See the Ultimate Guide to NHIs and the The 2025 State of NHIs and Secrets in Cybersecurity for the underlying exposure patterns.
CSV remains useful when the goal is manual review, migration, or interoperability with systems that cannot decrypt the source format. In practice, though, that convenience should be limited to controlled workflows because the plain-text nature of CSV makes it much easier to leak through download folders, support tickets, spreadsheets, and ad hoc sharing.
Where encrypted JSON is safer, and where CSV still has a role
Encrypted JSON is usually the better choice when the export may be stored, transferred, or retained beyond a short-lived administrative task. It is especially important when the file might be handled by someone outside the owning account, because the encryption layer keeps the entries unreadable without the correct key material.
CSV has a narrower but legitimate role. Teams still use it when they need to sort, filter, reconcile, or import data into legacy tools. The trade-off is that the file behaves like ordinary text, so any downstream control failure, accidental attachment, or cloud sync can expose the contents immediately.
That trade-off is why the decision is less about “best format” and more about “best format for the handling path.” If the export will ever leave a tightly controlled workflow, encrypted JSON is the defensible default. If a CSV is necessary, it should be treated like sensitive credentials from the moment it is generated.
For readers who want a broader view of how exports connect to secret leakage and vault handling, Guide to the Secret Sprawl Challenge and the The 2024 State of Secrets Management Survey are useful complements. They show why exports, copies, and duplicate storage often become the path of least resistance to exposure.
Export format also changes the blast radius after theft. An encrypted JSON export raises the bar because an attacker still needs the key or password to read the data, while a CSV export gives immediate access to whatever was inside the vault at the time of export. That difference matters most when the exported file contains many entries, high-value credentials, or broadly reused secrets.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Secrets and Credential Management | Exported vault data contains secrets that must remain protected outside the source vault. |
| NHI-05 — Lifecycle and Rotation | Exports can create duplicate secret copies that outlive the source and widen exposure. | |
| Recommendation — Prefer encrypted export formats and restrict plain-text secret exports to tightly controlled workflows. Rotate or revoke secrets after uncontrolled exports and minimise duplicate copies. | ||
| CIS Controls v8 | 6.2 — Address Unauthorized Assets | Plain-text exports are sensitive assets that can be copied, stored, and exposed outside approved locations. |
| 3.4 — Securely Dispose of Data | Old CSV exports can persist as readable sensitive data long after operational use ends. | |
| Recommendation — Inventory exported secret files and remove any copies stored outside approved repositories. Delete obsolete exports securely once the business need for the file has passed. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Control | Encrypted exports enforce access to secret material through protected key or password control. |
| PR.DS-1 — Data-at-Rest Protection | Encrypted JSON protects exported secrets at rest, unlike plain-text CSV. | |
| PR.DS-5 — Data Leakage Prevention | CSV exports can leak through sharing, sync, or unmanaged storage channels. | |
| Recommendation — Limit export access to authorised users and require protected keys for any decryptable copy. Encrypt sensitive exports before storage or transfer. Apply controls that prevent sensitive exports from leaving approved handling paths. | ||
| NIST SP 800-63 | IAL/AAL/FAL — Authenticator and Federation Assurance | Decryptable exports depend on protected account access and strong authenticator handling. |
| Sec. 5 — Digital Identity Risk Management | Sensitive exports depend on safe handling of account keys and recovery paths. | |
| Recommendation — Use strong authenticators for accounts that can decrypt or generate sensitive exports. Protect the account recovery and key-handling process for any export-capable user. | ||
Practitioner Guidance
What to verify: Confirm whether the export is encrypted at rest, what key or password protects it, and whether that protection is separate from the storage location. If the file is intended for transport, assume it can be copied or forwarded and choose the format accordingly.
Decision rule: Use encrypted JSON for backup, transfer, or any workflow where the file may persist outside immediate control; use CSV only when a specific receiving process requires human-readable text and the handling risk is acceptable.
Common mistake: Treating “exported from a vault” as automatically safe. Once a CSV exists, it is no longer vault-protected in practice if it can be opened without the original account protection.
Practitioner takeaway: The format choice is really a handling choice, encrypted JSON preserves confidentiality if it stays protected, while CSV turns the export into readable secret material the moment it leaves controlled custody.
Related resources from NHI Mgmt Group
- What is the difference between a password generator and a password vault?
- What is the difference between portable passkeys and traditional password export methods?
- What is the difference between zero-knowledge password management and standard vault-based password storage?
- What is the difference between encrypted metadata and standard credential fields in access management workflows?
