Research Release Highlight: New Keeper Commander PAM Integration
Summary Tenable is proud to announce a new integration with Keeper Commander for use with Keeper Security providing streamlined privileged access in credentialed vulnerability scans. This integration is available in Tenable One Vulnerability Management and Tenable Nessus. Change Supported Credential Types: SSH, including privilege escalation (e.g., sudo) and SSH key-based authentication (with optional passphrase) SMB (Windows), including domain and Kerberos authentication Database: Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, DB2, Cassandra, Sybase ASE ESXi: VMware vSphere hypervisor credentials vCenter: VMware vCenter Server credentials Nutanix: Nutanix Prism Central credentials For comprehensive details regarding this integration, please refer to the Tenable user https://docs.tenable.com/Integrations.htm. Impact There is no disruption to existing scan configurations. Customers using Keeper Security for privileged access management are encouraged to adopt this integration for credentialed scanning to consolidate credential management and reduce risk from static credentials stored in scan policies. Release Date 8 October 2026 for Tenable One Vulnerability Management and Tenable Nessus TDB for Tenable Security Center
Improvement To Plugin 142960 “HSTS Missing From HTTPS Server (RFC 6797)”
Summary Plugin 142960 now validates the identity of an HTTPS service in line with the current RFC 9525 as opposed to the obsolete RFC 6125. When a service's TLS certificate contains Subject Alternative Name (SAN) entries, the plugin compares the target hostname against those SANs only and no longer considers the certificate's Common Name (CN). If the certificate has no SANs, the plugin falls back to using the CN, so coverage for legacy certificates is unchanged. Background Plugin 142960 checks whether a detected web server supports HTTP Strict Transport Security (HSTS). Before it evaluates the service, the plugin must confirm that the service's TLS certificate covers the identity of the host. This confirms that the server is authorized to answer for that host, and that the finding describes the target host and not whichever service happened to respond on its behalf. If the identity check fails, the plugin cannot evaluate the service. Until now, the plugin performed this check by comparing the resolvable hostname against the CN of the certificate presented on the relevant port. If the CN covered the hostname, the service was evaluated for HSTS. RFC 9525, which supersedes the identity-matching guidance in RFC 6125 (which allowed for the checking of CNs) states that when a certificate carries one or more SAN entries, hostname identity must be validated against those SANs only. The CN must not be used for this purpose, even if it matches the hostname. The RFC gives several reasons: the CN is ambiguous, it cannot hold multiple identifiers, and its use leads to security and parsing inconsistencies. This change was prompted by a case in which a host's service could only be identified through the SAN of its certificate and not through the CN. Research into that case led to RFC 9525, and the update follows its guidance. Changes Service identity validation in plugin 142960 now works as follows: If SANs were enumerated from the service's TLS certificate, the hostname is compared against the SANs only. The CN is not used, even when it matches the hostname. If no SANs were enumerated from the certificate, the plugin uses the CN to validate the service identity, as it did before. Impact For services whose certificates include SANs, the outcome of the identity check depends only on the SAN values. A service whose SANs cover the hostname but whose CN does not will now be validated and evaluated for HSTS. A service whose CN matches the hostname but whose SANs do not will no longer pass validation, so the plugin will not evaluate it. Services with certificates that have no SANs are evaluated as before. Affected Plugins 142960 - HSTS Missing From HTTPS Server (RFC 6797) Targeted Release Date Monday, October 12, 2026Arcon Converged Identity (CI) Platform
Summary Tenable One Vulnerability Management and Tenable Security Center now fully support the Arcon Converged Identity (CI) PAM solution. Using the existing Arcon PAM authentication type alongside Digital Vault API configuration, customers with Arcon CI-PAM can seamlessly retrieve credentials during scans. Change No new scan configuration fields or credential types are required. Customers using Arcon CI-PAM should configure the Authentication URL and Engine URL to point to the Digital Vault API base path (e.g. dv/api/sdk), as with Arcon DV deployments. Impact No changes to existing scan configurations are required. Customers currently using the legacy Arcon PAM API path are unaffected. Release Date 8 September 2026 for Tenable One Vulnerability Management, Nessus and Tenable Security CenterNew Microsoft Azure Key Vault Integration
Summary We are pleased to announce that Tenable's credentialed scanning now supports Microsoft Azure Key Vault as a Privileged Access Management (PAM) integration. This will be available in Tenable One Vulnerability Management and Tenable Nessus Immediately. Change Tenable's credentialed scanning has been updated to include Microsoft Azure Key Vault as a new authentication method. Security teams can now store privileged credentials in Azure Key Vault and have Tenable retrieve them automatically at scan time using OAuth2 client-credentials authentication with a Microsoft Entra ID service principal. Credentials such as sensitive passwords and SSH private keys are maintained centrally inside the vault, they are never stored in Tenable scan policies and can be rotated seamlessly without requiring manual policy updates. The Azure Key Vault integration supports the following credential types: SSH Windows (SMB) Database (Oracle, SQL Server, MySQL, PostgreSQL, DB2, MongoDB) VMware ESXi SOAP API VMware vCenter API Nutanix Prism Central Each Key Vault secret is expected to hold a JSON object containing one or more of the fields username, password, ssh_key, ssh_keyphrase, and domain, so a single secret can drive both password and SSH private-key-based target authentication. For SSH targets, privilege escalation may optionally reference a separate Key Vault secret whose password field is used as the sudo/su password. For more information see our Microsoft Azure Key Vault Integration user documentation: https://docs.tenable.com/Integrations.htm Impact No impact to current scans are expected; If customers encounter issues with this integration, please open a ticket with Technical Support. Release Date September 3, 2026 for Tenable One Vulnerability Management and Nessus TBD for Tenable Security CenterArcon PAM New Digital Vault API Support
Summary Tenable is proud to announce expanded support for the Arcon Privileged Access Management (PAM) integration in Nessus. The integration now supports the Arcon PAM Digital Vault (DV) API. Customers who have migrated to Arcon DV deployments can now retrieve credentials through Nessus scans without requiring new credential types or additional scan configuration fields. This integration automatically selects the correct API path based on the Authentication URL and Engine URL configured in the scan credential. If the configured URLs contain dv/api/sdk, the Digital Vault path is used; otherwise the legacy path is used. No new scan configuration fields are required. Further information regarding these changes and configuration guidance for both API paths can be found in the Arcon section of Tenable's Integrations documentation page. Change The Arcon PAM credential now supports the Digital Vault API path alongside the existing legacy API. The DV path uses a distinct authentication endpoint and credential retrieval endpoint. These differences are handled automatically by the integration based on the URLs the user configures. Customers on DV deployments should set the Authentication URL and Engine URL to point to the DV base path (e.g. dv/api/sdk). Impact Existing scan configurations using the legacy API path remain unaffected. No changes to existing scan configurations or credentials are required for customers already using the legacy API. Release Date August 25, 2026 for Tenable One Vulnerability Management and Nessus TBD for Tenable Security CenterVMware Integration vSphere 9.0 Compatibility
Summary We are pleased to announce that Tenable's VMware integration for vulnerability scanning now supports VMware vSphere 9.0 (ESXi 9.0 and vCenter Server 9.0). These updates will be available in Tenable Vulnerability Management, Nessus, and Tenable Security Center. Change Tenable has updated its VMware integration to support VMware ESXi 9.0 and VMware vCenter Server 9.0. Authenticated vulnerability scans can now be performed on these targets without the need for additional credential setup. VMware vSphere 9.0 compatibility covers the following scenarios: VMware ESX SOAP API authenticated scans against ESXi 9.0 hosts VMware vCenter API authenticated scans against vCenter Server 9.0 VMware vCenter auto-discovery flows for 9.0 hosts For more information see our user documentation: Welcome to Tenable for VMware Impact No impact to current scans are expected; existing ESXi 8.x and earlier vCenter scans continue to work as before. If customers encounter issues with this integration, please open a ticket with Technical Support. Tenable will engage with VMware as needed to identify and resolve any issues. Release Date Available Immediately (May 27, 2026) for Tenable Vulnerability Management, Nessus, and Tenable Security Center Note: TDB for updates to enable VMware ESXi 9.0 and VMware vCenter Server 9.0 compatibility with Compliance and Audit scanning.New AWS Secrets Manager PAM Integration
Summary Tenable is proud to announce our new AWS Secrets Manager Privileged Access Management (PAM) integration. Customers can store scan credentials in AWS Secrets Manager and have Tenable retrieve them at scan time directly inside Tenable. These updates are immediately available for Tenable Vulnerability Management and Tenable Nessus, with plans to release this feature at a later date for Tenable Security Center. Change With this addition, scans can authenticate to targets using credentials fetched from AWS Secrets Manager using AWS Signature Version 4. This integration retrieves the secrets (username, password, optional SSH key, and optional domain) at scan time and uses them for credentialed checks, eliminating the need to store target credentials in Tenable Vulnerability Management or Tenable Nessus. AWS Secrets Manager authentication method supports the following credential types: Windows SSH Database (PostgreSQL, MongoDB, Cassandra, DB2, MySQL, SQL Server, Oracle) VMware ESX SOAP API VMware vCenter API Nutanix Prism Central Support is provided for both long-lived IAM user access keys and temporary AWS STS session tokens. Additionally, you can utilize the Escalation Credential ID to reference a separate AWS secret for SSH credential privilege escalation. Impact No impact to current scans are expected; If customers encounter issues with this integration, please open a ticket with Technical Support. For comprehensive details regarding this integration, please refer to the Tenable user documentation. Release Date July 16 2026 for Tenable Vulnerability Management and Nessus; TBD for Tenable Security CenterNew Akeyless PAM Integration
Tenable is pleased to announce a new integration with Akeyless Privileged Access Manager (PAM) for streamlined privileged access in credentialed vulnerability scans. This integration is available in Tenable Vulnerability Management and Tenable Nessus. Supported Credential Types SSH — including privilege escalation (e.g., sudo) and SSH key-based authentication SMB (Windows) — including domain and Kerberos authentication Database — Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, DB2, Cassandra, Sybase ASE ESXi — VMware vSphere hypervisor credentials vCenter — VMware vCenter Server credentials Nutanix — Nutanix Prism Central credentials Supported Authentication Methods The integration supports three methods for authenticating to Akeyless: Access Key — authenticate using an Akeyless Access ID and Access Key Universal Identity (UID) — authenticate using a Universal Identity token, supplied directly or read from a file on the scanner host Certificate (mTLS) — authenticate using a client certificate and private key Impact There is no disruption to existing scan configurations. Customers using Akeyless for privileged access management are encouraged to adopt this integration for credentialed scanning to consolidate credential management and reduce risk from static credentials. For comprehensive details regarding this integration, please refer to the Tenable user documentation. Release Date July 14, 2026 for T.VM and Nessus; TDB for T.SCHashiCorp Vault Integration - New SSH Certificate Authentication
Summary Tenable is proud to announce the addition of SSH Certificate authentication to our HashiCorp Vault integration. This feature allows customers to leverage HashiCorp Vault’s SSH Secrets Engine to retrieve signed SSH certificates during credentialed scanning for use in SSH authentication to target systems. Hence providing a more secure and streamlined approach to privileged access management. This update is now available in Tenable Vulnerability Management and Tenable Nessus, with plans to release for Tenable Security Center at a later date. By using the HashiCorp Vault with the SSH Signed Certificates option, users can centralize the management of their SSH secrets while reducing sprawling. Documentation for the Hashicicorp integration will be available on our documentation page. Supported Credential Types The HashiCorp Vault integration supports: SSH, including (least privilege, privilege escalation, SSH key authentication and SSH Signed Certificates). SMB (Windows), including domain configuration. SNMPv3 Database integration, including the following database types: Oracle SQL Server MySQL MongoDB PostgreSQL DB2 Cassandra Sybase ASE VMware vCenter API VMware ESX SOAP API Nutanix Prism Central Impact There is no impact to existing scan configurations.. Release Date Immediate; July, 6th 2026 for T.VM and Nessus, TDB for T.SC
Research Release Highlight – "Fully Scan Operational Technology" Default Setting Change
Summary The "Fully Scan Operational Technology" (OT) preference controls whether Nessus actively scans OT/ICS devices during a scan. This setting is intended to be disabled by default to avoid unintended disruption to sensitive operational technology environments. A long-standing setting in the Do not scan operational technology devices plugin caused this preference to default to enabled in a Basic Network Scan when the discovery type is not set to Custom. Change The default value for "Fully Scan Operational Technology" preference has been corrected from yes to no. Impact This fix will affect existing Basic Network scans automatically upon the next feed update — no scan recreation is required. Customers using Basic Network Scan policies with a non-custom discovery scan type will see the following behavioral change: Before change: "Fully Scan Operational Technology" was silently enabled, meaning OT devices may have been actively scanned. After change: "Fully Scan Operational Technology" will correctly default to disabled. Customers who intentionally want to scan OT devices should explicitly enable the "Fully Scan Operational Technology" preference by switching their scan policy's discovery type to Custom, which will expose the preference in the UI and allow it to be toggled on. Affected products: Tenable Security Center (SC), Tenable Vulnerability Management (TVM), and Nessus Target Release Date July 13, 2026