**TL;DR:** The vault denies public access and your caller is not on the private link. Distinguish firewall 403 from RBAC 403 before changing roles. Fix: add the caller IP, or add a private endpoint in the caller's VNet. Fix: grant Key Vault Secrets User.

## The fix

1. **Network 403.** Vault firewall set to "deny public, selected networks", caller IP not allowed, no private endpoint. Fix: add the caller IP, or add a private endpoint in the caller's VNet. Azure services calling the vault need "Allow trusted services" enabled.

2. **RBAC 403.** Names a missing action like `Microsoft.KeyVault/vaults/secrets/getSecret/action`. Fix: grant Key Vault Secrets User. Tell them apart: the network 403 has no action string. If the error names an action, it is RBAC. If it is a bare 403, it is network. Private endpoint checklist:

3. DNS resolves the vault name to the private IP (check with nslookup from the caller). If it resolves to the public IP, the private DNS zone link is missing.

4. The endpoint is approved (Pending = traffic still blocked).

5. NSG on the caller subnet allows 443 to the endpoint. Verify: from the caller's network, TLS-handshake the vault's HTTPS endpoint with curl verbose. An HTTP 401 without auth is fine, it proves network. Connection timeout = network; 401 = network OK, now fix auth.

## When to use this

- This covers exactly what the title says: Azure Key Vault 403 behind firewall or private endpoint.
- You are setting this up for the first time, or auditing an existing setup.
- You want the key gotchas in one place before you start.

## When not to use this

- You are doing a different workflow with Azure; these steps are specific to the title above.
- You need the full reference docs; this is the short path, not the manual.

## Compatibility

- Not pinned to a specific version; follows current Azure behavior.