# Azure Key Vault alternative for app secrets: Crunu vs Azure > Crunu vs Azure Key Vault for app secrets and .env files: who decrypts, Microsoft's advice on extra encryption, access per vault or environment, CI and pricing. URL: https://crunu.com/alternatives/azure-key-vault Language: en Updated: 2026-10-30 Azure Key Vault encrypts secrets when you add them and decrypts them when you read them, with access set per vault through Microsoft Entra ID. It suits workloads on Azure. Crunu encrypts every value on your devices before upload, the extra layer Microsoft suggests for sensitive data, and splits access per environment. Azure Key Vault decrypts your secrets automatically when you read them; Crunu encrypts them on your devices so its server never can. Key Vault is the managed Azure service for secrets, keys and certificates: Microsoft Entra ID authenticates every caller, access is set per vault, and the service encrypts each secret when you add it. Crunu is a team vault for environment variables, cloud credentials and API keys, encrypted before upload and delivered to laptops, servers and CI pipelines in any cloud. Microsoft's own documentation adds a line that frames this whole comparison. For highly sensitive data, it suggests adding extra layers of protection, for example encrypting data with a separate protection key before storing it in Key Vault. That extra layer is exactly what Crunu does for every value. > **Note:** We checked every statement about Azure Key Vault against Microsoft Learn, the Azure CLI reference and the Azure pricing page on October 30, 2026. Sources are listed with this page. If something is out of date, tell us at . ## Who each one fits **Azure Key Vault fits** teams whose workloads run on Azure and authenticate through Microsoft Entra ID, with managed identities instead of stored credentials. It fits teams that keep keys and certificates next to secrets, want FIPS-validated modules behind the service, run on AKS, and prefer to stay inside one Azure subscription and bill. **Crunu fits** teams whose `.env` files, cloud credentials and API keys travel beyond one cloud: developers' laptops, servers at several providers, CI on GitHub, GitLab or Bitbucket. It fits teams that want values encrypted before the store sees them, access per environment in one place, and a precise report of what a departing person received. ## Side by side | | Azure Key Vault | Crunu | | -------------------------- | --------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Where values are decrypted | In the service: Key Vault encrypts secrets when you add them and decrypts them automatically when you read them | Only in the browser and the `crunu` agent. The server stores ciphertext and signed documents. | | Extra protection | For highly sensitive data, Microsoft suggests encrypting with a separate protection key before storing it | Every value is encrypted on your device before upload, by default | | Access control | Set at the level of the key vault, through Azure roles or legacy access policies | Per environment: Editor, Reader, Specific files and Operator, in access lists signed by an administrator | | Keys per environment | Microsoft advises one vault per application, region and environment | Each environment has its own key, sealed separately to each person and machine allowed to read it | | Size limit | Up to 25 KB per secret | Up to 1 MB per environment, holding `.env`, INI, YAML or plain text files | | Sign-in for people | Microsoft Entra ID authenticates every caller | Password plus Secret Key, with an optional authenticator code or passkey. No SSO. | | CI sign-in | GitHub Actions sign in with OIDC through federated identity credentials in Microsoft Entra | Service tokens bound by OIDC to repository, branch and deployment environment on GitHub Actions, GitLab CI, Bitbucket Pipelines or any issuer | | Rotation | Automated with an Azure Function you deploy | Rotates its own encryption keys. Values at providers are reissued by hand, from a checklist. | | Where it runs | A managed Azure service | Crunu cloud at app.crunu.com; on the Enterprise plan, also your own server on Docker, Cloudflare Workers, Vercel or Google Cloud Run | | Audit | Logging saves operation records to an Azure storage account you provide | Hash-chained audit log, 365 days by default and extendable, with JSONL export | | Kubernetes | Azure Key Vault provider for the Secrets Store CSI Driver on AKS | Not available | | Pricing model | Billed per 10,000 operations; new Azure accounts get time-limited credits | Free during early access in the Crunu cloud; self-hosting on the Enterprise plan | ## Microsoft's advice, applied by default *Figure: Diagram of who can decrypt Azure Key Vault values, split into your side and the provider side. On your side, your team’s devices, your machines, and CI runners can decrypt. On the provider side, the Azure Key Vault service holds the key and can decrypt values too. Cloud IAM principals with decrypt permission can decrypt as well.* Key Vault stores every secret as encrypted data, behind a hierarchy of keys protected by FIPS-validated modules, with an encryption leaf key unique to each vault. This encryption is transparent: the service encrypts a secret when you add it and decrypts it automatically when an authorized caller reads it. That is encryption at rest, and it is done well. It also means the service, not your device, turns ciphertext back into the value. Microsoft's answer for highly sensitive data is a second layer: encrypt the data with a separate protection key before it reaches Key Vault. Crunu builds that layer in for everything. Values are encrypted in the browser or the `crunu` agent with an environment key the server never has, and decrypted only where that key lives: a teammate's browser, an enrolled server running `crunu daemon`, or a CI runner with a service token. There is no separate key for you to manage, store and hand out, because each environment key is sealed to the public keys of the people and machines allowed to read it. ### One vault per environment, or one environment per key Key Vault sets access at the level of the vault, so Microsoft advises one vault per application, region and environment. A team with three applications in two regions and three stages ends up managing many vaults and their role assignments. In Crunu, the environment is already the unit of encryption and access: a project holds `development`, `staging` and `production`, and a developer with access to `development` never receives the `production` key. When someone leaves, Key Vault access ends when their Entra ID account or role assignment does, and the logs in your storage account show what they read if logging was on. Crunu's [member removal flow](https://crunu.com/features/offboarding) rotates the keys of every environment the person could read, shows which versions they received, and lists the values to reissue at providers. Values already seen stay valid until reissued, as the [limitations page](https://crunu.com/security/limitations) explains. ## Where Azure Key Vault is stronger - **Microsoft Entra ID.** Every caller authenticates through your directory, so sign-in, accounts and managed identities come from the same place. Crunu has no SSO and no SCIM. - **Keys and certificates too.** Key Vault manages secrets, keys and certificates in one service, behind FIPS-validated modules. Crunu stores secrets only. - **Azure-native delivery.** Managed identities, a Secrets Store CSI Driver provider on AKS and rotation with Azure Functions. Crunu has no Kubernetes support. - **Nothing new to adopt.** It lives in your subscription and bill. Crunu is a new vendor in early access, with no external audit published. ## Moving from Azure Key Vault to Crunu > **Note:** Crunu has no importer for Azure Key Vault. You read each secret with the Azure CLI on a trusted computer, write the values into `.env` files and drag the files into Crunu. 1. [Create an account](https://crunu.com/signup) and save your Emergency Kit. 2. Turn each vault into a Crunu environment, for example a production vault for `payments-api` into `payments-api` / `production`. 3. On a trusted computer, run `az keyvault secret list --vault-name ` to see the secret names in a vault. 4. Read each value with `az keyvault secret show --vault-name --name --query value -o tsv` and write it into a `.env` file under the variable name your app expects. 5. Drag the files into the matching environments, then delete the plaintext copies. 6. Start programs with `crunu run --env payments-api/production -- npm start`, enroll servers as machines, and give pipelines service tokens with OIDC binding. Keys, certificates, managed identity access and AKS delivery stay in Azure. You can keep Key Vault for those and move only the team's environment variables. > **Warning:** The files from step 4 hold plaintext secrets. Keep them out of Git and synced folders, and delete them after the import. ## Other Azure Key Vault alternatives The other big clouds work the same way. [AWS Secrets Manager](https://crunu.com/alternatives/aws-secrets-manager) decrypts each secret with AWS KMS before returning it, and in [Google Secret Manager](https://crunu.com/alternatives/google-secret-manager) the service decrypts even when you bring your own key. If your workloads span clouds, [HashiCorp Vault](https://crunu.com/alternatives/hashicorp-vault) is the self-hosted option to consider, with dynamic credentials across providers. If you want to manage secrets in one place and still have them land in Key Vault, [Doppler](https://crunu.com/alternatives/doppler) pushes values into AWS, GCP and Azure stores, and [Keeper Secrets Manager](https://crunu.com/alternatives/keeper-secrets-manager) has a one-way sync into Azure Key Vault. [Phase](https://crunu.com/alternatives/phase) can bind an Azure managed identity or service principal to a Phase service account, and decrypts on your devices by default. The article [customer-managed keys: who decrypts?](https://crunu.com/blog/customer-managed-keys-who-decrypts) compares how Azure, AWS and Google Cloud handle your own keys, and the guide [who can decrypt your secrets](https://crunu.com/guides/who-can-decrypt-your-secrets) covers every product we compare. ## FAQ ### Is Crunu an alternative to Azure Key Vault? Yes, for application secrets and `.env` files used by people, servers and CI, especially outside Azure. For keys, certificates and workloads on Azure that read secrets through managed identities, Key Vault remains the simpler fit, and you can use both. ### How do I move from Azure Key Vault to Crunu? List each vault's secrets with `az keyvault secret list`, read each value with `az keyvault secret show --query value -o tsv` on a trusted computer, and write them into a `.env` file. Drag the file into a Crunu environment, delete the plaintext copy, and switch programs to `crunu run`. ### Can Microsoft read secrets in Azure Key Vault? The service decrypts secrets automatically when an authorized caller reads them. For highly sensitive data, Microsoft suggests encrypting with a separate protection key before storing it in Key Vault. Crunu applies that kind of protection to every value: the server never holds a key that decrypts it. ### Why does Microsoft recommend one vault per environment? Because access control for secrets is set at the level of the vault that holds them. To keep production apart from development, you put them in different vaults. In Crunu, each environment has its own key and its own access list inside one project. ### Does Crunu work with Microsoft Entra ID? Not for signing people in: Crunu has no SSO or SCIM. People sign in with a password, a Secret Key and an optional second factor. For CI, Crunu service tokens accept OIDC tokens from GitHub Actions, GitLab CI, Bitbucket Pipelines or any OIDC issuer you configure. ## Sources - [Azure Key Vault: About secrets](https://learn.microsoft.com/en-us/azure/key-vault/secrets/about-secrets) (accessed 2026-10-30) - [Azure Key Vault: Overview](https://learn.microsoft.com/en-us/azure/key-vault/general/overview) (accessed 2026-10-30) - [Azure Key Vault: Secure your key vault](https://learn.microsoft.com/en-us/azure/key-vault/general/secure-key-vault) (accessed 2026-10-30) - [Azure Key Vault: Logging](https://learn.microsoft.com/en-us/azure/key-vault/general/logging) (accessed 2026-10-30) - [Azure Key Vault: Automate secret rotation](https://learn.microsoft.com/en-us/azure/key-vault/secrets/tutorial-rotation) (accessed 2026-10-30) - [Microsoft Learn: Use GitHub Actions with OpenID Connect to connect to Azure](https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure-openid-connect) (accessed 2026-10-30) - [AKS: Azure Key Vault provider for Secrets Store CSI Driver](https://learn.microsoft.com/en-us/azure/aks/csi-secrets-store-driver) (accessed 2026-10-30) - [Azure CLI reference: az keyvault secret](https://learn.microsoft.com/en-us/cli/azure/keyvault/secret?view=azure-cli-latest) (accessed 2026-10-30) - [Azure Key Vault pricing](https://azure.microsoft.com/en-us/pricing/details/key-vault/) (accessed 2026-10-30) - [AWS Secrets Manager: Secret encryption and decryption](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html) (accessed 2026-10-30) - [Google Cloud Secret Manager: Customer-managed encryption keys](https://docs.cloud.google.com/secret-manager/docs/cmek) (accessed 2026-10-30) - [Doppler integrations](https://docs.doppler.com/docs/integrations) (accessed 2026-10-30) - [Keeper docs: Sync command](https://docs.keeper.io/en/keeperpam/secrets-manager/secrets-manager-command-line-interface/sync-command) (accessed 2026-10-30) - [Phase: External identities](https://docs.phase.dev/access-control/external-identities) (accessed 2026-10-30) - [Phase security](https://phase.dev/security/) (accessed 2026-10-30)