Azure Key Vault is a supported identity source in Wire. If your secrets are already governed by Azure, this keeps them there - Wire reads a secret at the moment of login and never holds a copy. This is what Azure Key Vault automation looks like for logins behind an account: read one secret, use it, keep only the session.
The short version: register an app in Entra ID, copy its client secret's Value, grant it the Azure Key Vault RBAC role Key Vault Secrets User (not Key Vault Reader) on each vault, and give Wire the vault URLs. That's four steps rather than one, and the reason explains most of what follows.
Why you supply the vault list
Other integrations discover what they can reach. Azure won't let us.
There is no data-plane API that lists the vaults a service principal can access. Enumerating them means Azure's management plane - a different token scope and subscription- or resource-group-level Reader access. That is a far larger grant than "read some secrets," and asking you for it so we could populate a dropdown would be a bad trade.
So Wire doesn't ask. You provide the vault URLs at connect time, and that list is the scope. Wire refuses to read from any vault outside it - enforced on every single resolution, not just at setup, so a malformed or tampered reference can't reach a vault you never named.
The four steps
| # | Step | What it is |
|---|---|---|
| 1 | App registration | Entra ID → client ID + tenant ID |
| 2 | Client secret | Copy the Value, not the ID |
| 3 | Role per vault | Key Vault Secrets User |
| 4 | Vault URLs | One per line - this is the scope |
Two things reliably go wrong.
In step two, the portal shows a Value and a Secret ID next to each other. You need the Value, and it's shown exactly once - navigate away and you'll be generating a new one.
Step three is the one everyone gets wrong, and it deserves its own heading.
The role everyone gets wrong
Azure offers a role called Key Vault Reader. It sounds correct. It is not the one you want.
Key Vault Reader grants access to metadata. With it, Wire can list every secret name in the vault and receives a 403 on every attempt to read a value. The failure is maddening precisely because it looks like it's working - the browse populates, the picker fills, everything appears connected, and then every sign-in fails.
The role you want is Key Vault Secrets User, assigned on each vault you connect. Azure allows broader assignments, but a resource-group grant reaches every vault in that group, so vault scope keeps the grant matched to the list you give Wire. If you connect four vaults and assign the role on three, the fourth fails on its own - which is why Wire verifies every vault at connect time and names the specific one that's missing a grant. If a vault still uses the older access-policy model instead of RBAC, the equivalent is an access policy granting Get and List on secrets.
Why Azure needs two words for "no"
Authentication and authorization are separate systems here. Microsoft Entra ID answers who are you and issues an access token that lasts 60 to 90 minutes by default. Each vault's RBAC answers what may you read. A completely valid credential returns 403 on a vault it was never granted.
Wire treats those responses differently, and the difference decides whether a connection survives:
| Azure says | Meaning | Connection |
|---|---|---|
| 401 | Entra rejected the principal | REVOKED |
| 403 | No role on this vault | KEPT |
| 404 | No vault or secret there | KEPT |
| 429 | Throttled | KEPT |
Collapse 401 and 403 into "access denied" and one missed role assignment tears down a connection that works everywhere else. Testing against a live tenant before the role existed, the connect failed with an error naming the vault and the role to grant - not "credentials rejected," which would have sent someone off to regenerate a client secret that was never the problem.
How to store the secret
An Azure secret is one opaque string. Unlike a password manager's login item, it has no username field and no password field - just a value, and some tags.
So Wire reads it three ways at once, and all three work:
| How you store it | What Wire does |
|---|---|
{"username": "…", "password": "…"} | Parses the JSON, each key becomes a field - recommended |
| Password as the value, username in a tag | Maps each field to where it actually lives |
| Username and password as two separate secrets | Maps each field to its own secret |
JSON is tried regardless of whether the content type says so, because plenty of secrets carry a JSON body with the content type unset.
One caution: tags are metadata, not secrets. Anyone who can list the vault can read them, and they're visible in the portal without any secret-read permission. A username in a tag is reasonable. A password in a tag is not a password you've protected.
Secret versioning, and why rotation just works
Azure keeps every version of a secret. A reference from Wire deliberately names the secret without pinning a version, which means latest - always.
Rotate the value in the vault and there's nothing to update here. The current session runs until it expires; the next sign-in picks up the new value. If your rotation is automated, this is entirely hands-off.
Every read lands in your own audit trail
Key Vault logs secret access through Azure Monitor like any other Azure resource. Point your vaults at a Log Analytics workspace and every read Wire performs shows up there - which secret, which vault, which principal, when.
That's the governance argument in one line: the evidence of what we accessed is produced by Azure, stored in your tenant, and queryable by your team using the tooling you already run. We can't edit it, we can't omit from it, and you don't need us to produce a report.
For anyone answering an audit, this is the difference between a vendor attestation and a primary record. One is a claim. The other is your own log.
Sovereign clouds
Public Azure, US Government, and China are all supported, and there's no setting to get wrong - the cloud is derived from the vault hostname, which also selects the right Entra authority. The two can't drift out of sync because they're read from the same place.
Things worth knowing before you commit
- Client secrets expire. Entra caps them at 24 months, and it doesn't report the expiry date through the token exchange - so Wire can't warn you. Put a reminder in a calendar. When the secret comes due, rotate the source instead of reconnecting: the source ID stays the same, so every identity bound to it keeps working. Surfacing the expiry is on our list.
- Vault firewalls need an allowlist. If your vaults restrict network access or use private endpoints, our egress addresses need permitting. Wire reports this as its own error, SOURCE_UNREACHABLE, rather than calling it a credential failure, but it can't work around it.
- Very large vaults are capped. Browsing lists up to 500 secrets per vault, and a larger vault is cut off at that point. Beyond that, filter the list by domain or reference secrets directly rather than picking from a list.
What Azure asks for, and what it gives back
Azure asks more of you at setup and gives more back in governance. Role assignments are made by the people who already make role assignments, in the system your auditors already read. Access is per-vault (scoping you define), versions are per secret, and revocation is removing a role - a thing your organisation already has a process for.
If your secrets live in Azure, keeping them there and letting Wire read one at a time is a smaller change to your security posture than moving them somewhere else would be.
Next in Identity & Access: 1Password vs Azure Key Vault - which vault for which team.
Set it up. Have your tenant ID, client ID, client secret and vault URLs to hand, and connecting Azure Key Vault as an identity source takes one sitting.
→ Get started with Wire · Docs
Frequently Asked Questions
Which Azure role does Wire need to read secrets from Key Vault?
Key Vault Secrets User, on each vault you connect. Key Vault Reader is the common mistake: it grants metadata only, so Wire can list every secret name and gets a 403 on every value. A vault on the older access-policy model needs an access policy granting Get and List on secrets instead.
Why does Wire ask for vault URLs instead of discovering them?
Azure has no data-plane API that lists the vaults a service principal can access, and enumerating them through the management plane needs a far larger grant. The URLs you supply become the scope: Wire verifies every vault at connect time and refuses to read from any vault outside the list.
Where can a security team see what Wire read?
In Azure itself. Key Vault logs secret access through Azure Monitor, so with your vaults pointed at a Log Analytics workspace every read shows which secret, which vault, which principal and when, stored in your own tenant.
What happens when a secret is rotated in Key Vault?
Nothing changes on the Wire side. A Wire reference names the secret without pinning a version, so it always reads the latest one. The current session runs until it expires and the next sign-in picks up the new value.
Does Wire work with Azure US Government and Azure China?
Yes. Public Azure, US Government and China are all supported, and the cloud is derived from the vault hostname, so there is no separate setting to get wrong.
What happens when the client secret expires?
Entra caps client secrets at 24 months and doesn't report the expiry through the token exchange, so set a reminder. When it comes due, rotate the source in Wire with a new secret instead of reconnecting, and every identity bound to it keeps working.