Secrets management best practices: From .env files to centralized control

If your team uses .env files, you already have a secrets management problem. They work for small systems, but they break down when you need to rotate sensitive credentials, manage access across services, or prove who accessed what. At that point, .env files stop being a convenience and start contributing to secrets sprawl and operational and security debt.

This guide breaks down five secrets management best practices that form a complete operational model. It covers how secrets and credentials should be stored, accessed, rotated, scanned, and audited. It also includes practical examples and a staged progression for adopting these controls in real systems.

TL;DR

.env files are a convenient way to load environment variables during local development, but they do not scale to production. As your infrastructure grows, you need structured controls to prevent drift, secret leakage, and loss of auditability.

To move toward a production-grade model:

• Centralize secrets in a single source of truth
• Enforce least privilege access per service or workload
• Automate secret rotation and revoke old credentials reliably
• Scan for secrets in commits and full Git history
• Maintain immutable audit logs for all secret operations

These controls work together to protect secrets and maintain traceability across the environments where they are used.

Why .env files are not a secrets management strategy

A real secrets management strategy answers five operational questions every day:

• Where is the source of truth? Which system holds the authoritative value for each secret?
• Who can access it? Which users, services, and workloads are allowed to read each secret, and why?
• How do changes propagate? How do you update a secret and roll it out across environments without inconsistency?
• How do you handle lifecycle events? How do you rotate credentials and revoke compromised or stale values?
• How do you prove what happened? Who accessed or changed a secret, and when did it happen?

.env files only address a narrow, local subset of these operational questions. They provide a configuration file, not a system of record. Once teams start copying files across machines, environments, and deployment systems, they lose a single source of truth.

They also do not enforce access control, coordinate updates across environments, automate rotation, or produce audit logs. In practice, teams that rely on .env files end up rebuilding these capabilities in ad hoc systems around them.

Industry reports show millions of new exposed secrets each year, and many repositories still contain at least one credential. .env files act as a local-first distribution layer for these secrets. They make it easy to move credentials between environments, but they do so without any built-in access control, auditability, or consistency guarantees. As a result, teams create multiple unmanaged copies of the same secret that drift across development, staging, production, and CI/CD systems.

To replace .env-based distribution with a controlled secrets management model, implement the following practices.

Best practice 1: Centralize secrets in a single source of truth

Centralization is the foundation for every other secrets control. If you cannot reliably locate a secret, you cannot rotate it, scope access to it, or audit its usage.

What centralization means in practice

Centralized secrets management establishes one authoritative value per secret, one access policy, and one audit trail. In contrast, file-based approaches often create multiple copies of the same credential across developer machines, CI runners, and deployment scripts, with no clear system of record.

A practical target state looks like this:

• A dedicated secrets management system acts as the source of truth.
• Applications and CI/CD pipelines retrieve secrets dynamically per environment.
• Access is granted to identities (services, workloads, users), not shared files.
• Every secret change is versioned, with read and modification history available.

Centralization is what makes consistent access control, rotation, and auditing possible across environments.

What to centralize first

Start with secrets that carry the highest blast radius, then expand to lower-risk or local-only values.

If you're manually copying values into .env files, stop treating them as the source of truth. Instead, store secrets in a centralized secrets manager and inject them into local, staging, and production environments from the same authoritative source.

Best practice 2: Apply least privilege to every secret

Enforce least privilege for every secret. Each workload should only have access to the credentials it needs, limiting the impact of exposed secrets.

Do not scope secrets by team, project, or environment alone. That’s too broad and becomes unsafe quickly. Instead, scope access to a specific service identity and its runtime role.

For example, if only your payment service needs a Stripe key, only that service should be able to read it. Define access explicitly using role-based access control (RBAC):

• Allow payments-api to read stripe_live_secret
• Allow checkout-worker to read queue_signing_key
• Do not allow analytics-job to access payment-related secrets

If you cannot express access at this level, your permissions are already too broad.

Access reviews and offboarding

Least privilege breaks down over time if you do not actively review access. As services evolve and engineers change roles, permissions accumulate beyond their original intent.

Run quarterly access reviews for all secrets with the relevant service owner, including both human and non-human identities. Revoke access immediately when an engineer leaves, changes roles, or when a service is deprecated or ownership changes. Rotate high-risk credentials after any offboarding event to limit exposure from lingering access. Record the outcome of each review so you can produce audit and compliance evidence when required.

Best practice 3: Automate secrets rotation

You should automate secret rotation wherever possible. Manual rotation does not scale. If you rely on people to rotate secrets, rotation will eventually be delayed, skipped, or forgotten. Automation is what turns rotation from a policy into an enforceable control.

What rotation must do

Secret rotation only works if it completes three steps in sequence. You generate a new secret value, you update all consumers within a controlled rollout window, and you revoke the old value so it can no longer be used. If any of these steps are missed or delayed, rotation does not meaningfully reduce risk. In practice, teams often skip or postpone rotation because coordinating changes across services is slow and error-prone.

Automated rotation solves this by removing coordination from the process. Modern systems use dynamic secrets that are generated on demand, expire automatically, and are revoked without manual intervention.

What auditors expect

Rotation is both a security control and a compliance requirement. You are expected to define a rotation policy, execute it consistently, and prove it with evidence.

• PCI DSS requires periodic changes for applicable credentials and verifiable proof that expired credentials are no longer valid.
• SOC 2 does not mandate a fixed interval, but it requires that your rotation policy be defined, risk-based, and consistently executed with evidence.
• ISO 27001 expects risk-based credential management with documented procedures and proof of ongoing enforcement.

Across all frameworks, the expectation is the same: you must show that secrets are rotated on a controlled schedule and that old credentials are no longer usable.

Best practice 4: Scan for hardcoded and committed secrets

To prevent secrets from leaking into version control, scan for credentials before they reach your main branch. Continuously scan your repository history for exposed credentials using tools such as GitGuardian, TruffleHog, or GitHub Secret Scanning.

Install pre-commit hooks that scan staged changes before code is committed. Enforce the same check in CI so every pull request is scanned before merging. Treat high-confidence findings as blocking failures. At a minimum, implement this pipeline:

• Pre-commit hooks scan staged diffs on developer machines
• CI runs a full secrets scan on every pull request
• High-confidence matches fail the build automatically
• A triage process separates real credentials from test data and false positives

This control is increasingly important. GitGuardian’s State of Secrets Sprawl makes it clear that secret leakage is still increasing, especially as AI-assisted coding increases commit speed and volume.

Scan Git history

Current file scanning is not enough. Secrets often persist in commit history even after they are removed from the latest version of the codebase. Run scheduled scans across repository history. When you find a real credential, treat it as exposed even if it is no longer present in the current files; then rotate it immediately.

You must also treat Git history scanning as a required control. Pair secret detection with a defined incident response process. When a secret is discovered, immediately assign ownership, contain exposure, and rotate the credential.

Best practice 5: Maintain an audit trail of secrets usage

Audit trails are essential anywhere sensitive data flows through multiple services. Maintain a complete audit trail for all secret operations. Without it, you cannot prove control effectiveness or investigate credential misuse. Your system must record every lifecycle event for a secret:

• Secret creation events
• Secret updates and version changes
• Secret deletion events
• Secret access events, including identity, service, and timestamp

Do not rely on systems that only log write operations. You need visibility into read events as well, so you can answer who accessed a secret and when. Incomplete logging is a common failure mode in distributed systems where secret management responsibilities are split across multiple tools and services.

Make audit logs tamper-resistant and reviewable

Treat audit logs as security evidence. Store them separately from the systems that access secrets so a compromised identity cannot modify or delete them. Retain logs for at least 12 months to meet audit requirements such as SOC 2 Type II. Restrict deletion and modification access to a tightly controlled security boundary. Ensure logs are immutable or write-once wherever possible, and forward them to a centralized security or SIEM system for long-term analysis.

Putting the practices together

Use the table below as a progression guide for moving from .env-based workflows to centralized secrets management. Your security and development teams can adopt these practices together in stages.

Each stage builds on the previous one, forming a complete control path from .env workflows to centralized secrets management.

Next steps

You now have a progression for secrets management that starts where you are and scales with your risk. .env files remain useful for local development, but they are only the starting point. Identify your current stage, apply the next control from the best practices outlined above, and use measurable evidence such as rotation logs, scan results, and audit trails to confirm the control is working as intended.

Reassess this model as your system evolves and apply the next control needed to eliminate your current failure modeIf you still use .env files and share secrets manually, move to a centralized secrets management system like Doppler to manage secrets, enforce access control, automate rotation, and maintain audit logs in a single system.