What should organisations do instead of sharing .env files?

Use a secrets manager or workload identity approach that delivers secrets to the process at runtime, tied to a specific human, server, or pipeline identity. That gives you control over access, rotation, and logging, while preserving the same application behaviour inside Python.

Why This Matters for Security Teams

Sharing .env files treats secrets as a packaging problem instead of an identity and runtime-access problem. That is risky because the same file often gets copied into laptops, CI jobs, container images, and chat threads, where it becomes difficult to rotate, revoke, and audit. NHI Management Group research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which turns a convenience shortcut into an enterprise exposure pattern.

Security teams should expect this issue to surface wherever development speed has outrun secret governance. The better question is not how to protect the file, but how to stop distributing reusable credentials at all. Guidance from the NIST Cybersecurity Framework 2.0 and NHI Management Group’s Ultimate Guide to NHIs both point toward stronger identity-centric controls, inventory, and lifecycle management. In practice, many security teams encounter secret sprawl only after a leaked file has already been reused across multiple environments.

How It Works in Practice

The practical replacement for shared .env files is runtime delivery of secrets through a secrets manager or workload identity model. The application should authenticate itself, prove what it is, and request only the secret it needs at the moment it needs it. That can be done with cloud workload identity, short-lived tokens, or identity federation, rather than a static file that must be copied everywhere.

A workable pattern usually looks like this:

• The process authenticates using a human, server, CI pipeline, or workload identity.
• The secrets manager returns a short-lived secret or token at runtime.
• Access is logged centrally so retrievals are attributable.
• Rotation happens in the backend, not by manually updating files across hosts.
• Revocation can target one workload without breaking every deployment that shares the same file.

This approach also aligns with the reality that many non-human identities are overprivileged. NHI Management Group reports that 97% of NHIs carry excessive privileges, which is why runtime access should be narrowly scoped and time-bound rather than baked into application packaging. For implementation patterns, NIST Cybersecurity Framework 2.0 supports access governance and recovery discipline, while the 230M AWS environment compromise case study illustrates how credential exposure scales when secrets are left broadly reachable.

These controls tend to break down when teams rely on static environment injection in long-lived containers, because the process may be restarted or cloned without re-authenticating and the same secret then follows every copy.

Common Variations and Edge Cases

Tighter secret delivery often increases deployment complexity, requiring organisations to balance operational convenience against stronger revocation and auditability. That tradeoff is real, especially in mixed estates where legacy apps cannot easily fetch secrets at runtime.

Current guidance suggests avoiding one-size-fits-all migration plans. Some systems can move quickly to secrets managers with native workload identity, while others may need a staged approach with short-lived wrappers around existing .env-style configuration. There is no universal standard for this yet, but best practice is evolving toward per-workload credentials, automatic rotation, and policy enforcement at retrieval time. Where human operators still need temporary access, just-in-time elevation is preferable to permanently shared files.

Edge cases include local development, air-gapped environments, and third-party integrations that still expect flat files. In those situations, teams should minimise lifetime, scope, and distribution, then treat the file as a temporary transport artifact rather than a source of truth. NHI Management Group’s research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which is why the operational hard part is usually not generation but cleanup. For broader governance context, refer to NHI Management Group’s Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.

Related resources from NHI Mgmt Group

• Why are local .env files and config notes risky in Microsoft 365?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How can organisations reduce secret leakage in ServiceNow at scale?
• How do organisations reduce false positives in secret detection pipelines?