No. The .NET Secret Manager tool, also called user secrets, is for development only. Microsoft's documentation says it does not encrypt stored secrets and should not be treated as a trusted store. Values sit in a JSON file in your user profile. Production should read secrets through a controlled means such as Azure Key Vault.
What user secrets are
Running dotnet user-secrets init adds a UserSecretsId to your project file. Values you set are stored outside the project tree, so they are not checked into source control. On Windows the file is under the AppData folder, and on Linux and macOS under a hidden .microsoft directory in the home folder, in a secrets.json keyed by that id.
The documentation is direct about the limits: Secret Manager "doesn't encrypt the stored secrets and shouldn't be treated as a trusted store. It's for development purposes only." It also tells developers not to write code that depends on the location or format of the stored data, because those details may change.
How it gets loaded
ASP.NET Core web apps created with the standard templates call AddUserSecrets when the environment name is Development. In non web projects such as console apps, you add the configuration and user secrets packages yourself. Because the source is added only for Development, a correctly configured production host does not read it.
Where each kind of secret belongs
| Context | Suitable | Not suitable |
|---|---|---|
| Local development | User secrets, or environment variables | Values in appsettings.json |
| CI | The CI platform's secret store, injected at run time | Files committed to the repo |
| Test and production | A managed store such as Azure Key Vault, through its configuration provider | User secrets, plaintext files |
The page states the principles: never store passwords or other sensitive data in source code or configuration files, production secrets should not be used for development or test, secrets should not be deployed with the app, and production secrets should be accessed through a controlled means like Azure Key Vault.
Environment variables are not a vault either
The same page warns that environment variables are commonly stored as plain unencrypted text, so if the machine or process is compromised they can be read by untrusted parties. OWASP's secrets guidance goes further and notes environment variables are generally accessible to all processes and may be included in logs or system dumps. They avoid putting values in code, but extra measures may be needed.
One practical tip from the docs: use a double underscore as the separator in environment variable names for hierarchical keys, since the colon does not work on every platform.
A safer connection string pattern
Do not put the password in appsettings.json. Keep the connection string without the password in configuration, and add the password at runtime from the secret source using a connection string builder. The documentation shows exactly this approach with a DbPassword secret.
Steps
- Run dotnet user-secrets init in each project that needs local secrets.
- Remove any real secrets from appsettings files and history.
- In test and production, configure a managed secret store and grant the app a narrow identity.
- Rotate any secret that was ever committed or shared, since removing it from the repo does not make it safe again.
- Scan the repository and build artifacts for leaked credentials.
- Document where each secret lives and who can read it.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a scan finds secrets left in source and configuration files.
Quick check
Is secrets.json encrypted on my laptop?
No. It is plain JSON in your user profile. Disk encryption protects it at rest, but any process running as you can read it.
Can I ship secrets.json with the app?
No. Microsoft's guidance is that secrets should not be deployed with the app.
Safeguard dependency scanning and SBOM generation cover the NuGet packages in your .NET service, and the free scan is at gold.safeguard.sh/scan.
Sources
- Safe storage of app secrets in development in ASP.NET Core (Microsoft Learn)
- OWASP Secrets Management Cheat Sheet
Last reviewed: 19 October 2026.
