What information does the Microsoft Azure Key Vault integration collect?

The Azure Key Vault Privileged Access Management (PAM) integration collects only the credential material required to authenticate to a scan target. The value of the Key Vault secret is parsed as a JSON object; the following fields are read from the secret when present:

  • username — the target account username.

  • password — the target account password.

  • ssh_key — a PEM-encoded SSH private key used to authenticate to SSH targets.

  • ssh_keyphrase — the passphrase protecting the SSH private key (mapped internally to passphrase).

  • domain — the Windows/Active Directory domain associated with the account (used only when Fetch Domain is enabled).

Note: password vs. ssh_key — If ssh_key is present in the secret, it is used as the SSH private key. If ssh_key is absent but the password value contains PEM markers (the literal text -----BEGIN or PRIVATE KEY), the integration treats the password field as an SSH private key. In every other case the password field is used as a plain password. The ssh_keyphrase field is only applied when one of those two SSH-key paths is taken.

If the Key Vault secret value is plain text rather than JSON, the entire string is treated as the password.

API requests per target

For each scan, the integration first performs one OAuth2 token request against https://login.microsoftonline.com/<tenant_id>/oauth2/v2.0/token to obtain a bearer access token. The access token is cached in-memory for the duration of the plugin execution and is reused for all subsequent secret retrievals. One additional GET request against https://<key_vault_name>.vault.azure.net/secrets/<secret_name>?api-version=7.4 is made for each distinct Key Vault secret referenced by the scan policy. If SSH privilege escalation is configured with an independent Escalation Credential ID, one extra GET request is issued to fetch that escalation secret.

Retrieved credentials are cached for the duration of the scan (keyed by secret name) to avoid repeated requests for the same secret. The cache is not shared between scan chunks, so each chunk will produce a minimum of one authentication request and one secret request.

Credentialed Scans

Credentialed scans allow the Tenable scanner to log in to the target system directly and perform a deeper assessment than is possible without credentials. This includes checking installed software versions, configuration settings, patch levels, and compliance status.

What the Microsoft Azure Key Vault integration does not collect

  • The integration does not collect vulnerability data, software inventory, device inventory, or configuration details from target systems — it only retrieves credentials that Tenable then uses to authenticate to those targets.

  • The integration does not read Azure Key Vault Keys or Certificates objects. The API returns only the public component of a private key, and the Certificates object stores its private key separately in the Secrets object using an X.509 PEM format that is not directly usable for standard OpenSSH authentication. Only the Secrets object is supported.

  • Managed identities are not used as an authentication method — the integration authenticates as a Microsoft Entra ID service principal using the OAuth2 client-credentials grant.

Note: For compliance audits, add audit files to your scan policy. The Azure Key Vault integration provides credentials, while the audit files define the checks performed.