Use an encrypted JSON export whenever possible, because standard CSV and JSON exports are readable if the file is exposed. Sync the vault first, export from the appropriate client, then store the backup in a locked drawer, safe, or other controlled location. If you must use CSV, add operating system level encryption and delete the original unencrypted file immediately.
Why the export format matters more than the backup job
The core issue is whether the backup artifact remains readable if it leaves controlled storage. A vault export can be a recovery asset, but it is also a high-value concentration of credentials, tokens, certificates, and other secrets. That is why encrypted export formats are preferred: the backup should preserve recoverability without turning the file itself into a plain-text exposure.
For that reason, standard CSV and JSON exports should be treated as convenience formats, not as safe backup formats. If the file is exposed through email, shared storage, endpoint compromise, or misplaced media, the contents may be immediately usable unless the export is encrypted end to end. The safest workflow is to sync first, then export from the correct client so you are backing up the current vault state rather than an inconsistent snapshot.
A useful reference point is the broader pattern of secrets sprawl and vault misconfiguration documented in NHI Mgmt Group’s Ultimate Guide to NHIs, which reinforces why exported secret material needs the same care as any other secrets-bearing system.
How to handle the file after export
The export process does not end when the file is written. The file needs a storage path that matches its sensitivity, and the original unencrypted version should be eliminated immediately if a protected format was not used. At minimum, that means keeping the backup in controlled physical storage or in a storage system with equivalent access restrictions and encryption.
If a CSV export is unavoidable, add operating system level encryption before the file is moved anywhere else, and avoid leaving an unencrypted copy behind on the source machine, desktop, downloads folder, or sync agent cache. The practical failure here is not just theft of the final backup, but accidental persistence of a readable copy on an endpoint, share, or removable device that is later reused or compromised.
When teams are unsure which export path is safe, the best navigation aid is Guide to the Secret Sprawl Challenge, because it focuses on how secrets leak through ordinary operational handling rather than only through deliberate theft.
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-01 — Secrets and Credential Management | Encrypted exports directly reduce exposure of secret-bearing vault data. |
| NHI-02 — Credential Lifecycle and Rotation | Backup handling affects how long exposed export material remains useful. | |
| NHI-09 — Secret Sprawl and Exposure Paths | CSV or unencrypted JSON exports create additional exposure paths for secrets. | |
| Recommendation — Export vault data only in encrypted form and protect any plaintext intermediary with immediate deletion and encryption. Minimise the lifetime of export files and rotate any credentials that may have been exposed during backup handling. Eliminate plaintext export paths and keep backup copies in tightly controlled storage. | ||
| CIS Controls v8 | 3.4 — Address Unauthorized Software and Data Exfiltration Risks | Backup exports can be exfiltration points if readable outside controlled storage. |
| 3.1 — Data Recovery Process | The question is specifically about backing up sensitive vault data for recovery. | |
| 3.2 — Data Backup | This maps directly to backing up sensitive data while preserving confidentiality. | |
| Recommendation — Protect exported vault files from unauthorized access and remove plaintext copies promptly. Use a recovery process that preserves encrypted exports and validates restore capability. Back up sensitive vault data with encryption and stored access controls that match the data sensitivity. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Encrypted export and controlled storage are data security measures for sensitive backup files. |
| PR.AC — Identity Management, Authentication and Access Control | Controlled storage requires limiting who can access exported vault backups. | |
| RC.RP — Recovery Planning | The answer includes keeping backups usable without exposing plaintext secrets. | |
| Recommendation — Encrypt backup exports and restrict storage access to preserve confidentiality. Limit access to exported backup files to authorised personnel and approved recovery systems. Test backup exports and restore procedures so recovery works without plaintext exposure. | ||
| NIST SP 800-63 | N/A — Digital Identity Guidelines | Identity assurance underpins who can access sensitive backup artifacts. |
| Recommendation — Require strong authenticated access before any user or process can retrieve vault exports. | ||
Practitioner Guidance
What to verify: Confirm that the export format is encrypted before the file ever leaves the exporting client, and test the restore path so the backup is usable without needing the original unencrypted artifact. If the export tool cannot produce an encrypted format, treat OS-level encryption and immediate deletion of the plaintext file as mandatory, not optional.
Common mistake: Teams often secure the storage location but forget the export lifecycle. That leaves a readable file on disk, in a temp directory, or in a synced folder long enough for endpoint backup tools, desktop search, or malware to capture it.
Decision rule: If the exported file contains live credentials, keys, or tokens, default to encrypted export plus controlled storage. Only use a plaintext export when there is a documented exception, a compensating encryption step, and a verified cleanup step for every intermediate copy.
Practitioner takeaway: Protect the export artifact as if it were production secrets, because in practice the backup file is often the easiest place for those secrets to escape.
Related resources from NHI Mgmt Group
- How should security teams expose programmatic access to encrypted vault data without weakening control boundaries?
- How should security teams manage secrets in Helm charts without exposing sensitive data in Git or cluster manifests?
- How should security teams handle AI client access to governed data without shared secrets?
- How should security teams back up GitHub configuration without weakening governance?
