Use strong, standard encryption with managed keys, and protect those keys separately from the encrypted files. Encrypt data at rest and in transit, restrict who can decrypt, and validate that backups and recovery processes still preserve confidentiality. Rotate keys where required, monitor access, and avoid storing secrets in plaintext alongside encrypted content.
What file encryption best practices actually need to protect
File encryption is only as strong as the key handling around it. The file contents can be cryptographically sound and still be exposed if the keys sit beside the data, are reused too broadly, or are reachable by too many people and systems. Good practice therefore treats encryption, key custody, access control, and recovery as one security design, not separate tasks.
That is why the first design choice is not just “encrypt the file”, but “who can decrypt, under what conditions, and how will that be audited.” A file encrypted with weak operational controls still fails the core objective: keeping readable content confidential when storage, backups, endpoints, or admin access are compromised.
How to apply encryption without weakening access, backup, or recovery
Use standard, well-reviewed encryption and keep the protection model simple enough to operate consistently. Encrypt sensitive files at rest and in transit, but make sure decryption rights are tightly scoped so only the people or systems that truly need the content can open it. For broader key lifecycle handling, Cryptographic Key Management Guide is the clearest companion for rotation, inventory, and separation of duties.
Separate encrypted files from the secrets that unlock them. If a backup archive, synced folder, repository, or document share contains both ciphertext and the decryption material, the control is weak in practice even if the algorithm is strong. The same applies to recovery workflows: test that restores still preserve confidentiality, and do not assume backup administrators should automatically be able to decrypt production content.
File encryption also fails when teams treat it as a one-time setup. Keys expire, staff leave, devices are lost, and file locations change. That means the operating model should include revocation, re-encryption where necessary, and periodic checks that the people and services still allowed to decrypt are the ones actually using the data. If the files are API-created or system-generated, the API Key Management Guide is useful for the same lifecycle discipline applied to machine credentials and access secrets.
Why file encryption breaks in real incidents
The most common failure is not “broken crypto”, it is exposed keys, overbroad access, or plaintext copies that survive alongside the protected files. Once attackers obtain the key material, encrypted files become ordinary readable data. Once insiders can decrypt everything by default, encryption only delays exposure rather than preventing it. Strong encryption therefore has to be paired with custody controls and narrow authorization boundaries.
Backups are a frequent weak point because they are designed for recoverability, not secrecy. If backup sets, export bundles, or archive vaults are copied into environments with weaker protection, the confidentiality boundary shifts silently. That is why encryption must be validated across the whole file lifecycle, including export, sync, retention, archive, and restore paths. The operational lesson in the GoTo breach 2023 is that encrypted backups still become a data exposure problem when the keys are reachable through a separate store.
Another recurring failure is secret sprawl. Teams sometimes keep passwords, tokens, SSH material, or recovery values in the same locations as the encrypted content for convenience. That shortens the attacker’s path from storage access to readable data and defeats the separation that encryption is meant to create. The breach pattern seen in CircleCI breach 2023 shows how quickly exposed secrets and keys can force emergency rotation across an environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | File encryption best practice here hinges on key lifecycle, separation, and rotation. |
| Recommendation — Apply key lifecycle policy so encryption keys are stored, rotated, and retired separately from protected files. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Encrypting sensitive files and protecting backups directly maps to safeguarding data at rest and in transit. |
| Recommendation — Encrypt sensitive data and protect backup copies with controls that preserve confidentiality across storage locations. | ||
| NIST SP 800-53 Rev 5 | SC-28 — Protection of Information at Rest | File encryption is a direct at-rest protection problem with confidentiality and recovery implications. |
| IA-5 — Authenticator Management | Key and secret rotation, revocation, and custody mirror authenticator lifecycle management. | |
| Recommendation — Implement at-rest protections that preserve confidentiality for stored files and backup media. Rotate and revoke decryption material on a defined schedule and after suspected exposure. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | This is the core Annex A control for applying cryptography to protect file confidentiality. |
| Recommendation — Define cryptographic use, key handling, and recovery rules for protected files. | ||
Practitioner Guidance
What to verify: Confirm that encrypted files, backup copies, and recovery exports are not protected by the same storage location as the keys or by a single administrative account. If the same operator can both retrieve the data and unlock it without an additional control, the design is too permissive.
Decision rule: If a file contains regulated, customer, or operationally sensitive content, treat decryption authority as a separate access decision from file access. If the file is low sensitivity but widely shared, keep the control lightweight and avoid creating needless recovery friction that users will work around.
What good looks like: Keys are inventoried, access is limited, backups can be restored without exposing plaintext to unintended roles, and rotation has a defined trigger, not an ad hoc response. If a key is ever suspected of exposure, assume any file it protected may already be compromised and move immediately to rotation or re-encryption.
Practitioner takeaway: File encryption is effective only when the key, the file, and the recovery path are governed separately; if those three things collapse into one trust boundary, confidentiality becomes fragile.
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 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org