Tenable One Cloud Exposure 2026 Completed Changes

Planned Release Date: Nov 8

What's Changing?

Cloud Exposure will automatically delete scan data for virtual machines and virtual machine images that have not been scanned for more than 30 days. Scan data includes vulnerabilities, software, and malicious files.

Deletion of old scan data happens 30 days after a resource stops being scanned, for example, when:

• You exclude the resource from scanning.
• You disable scanning.
• The marketplace product code is not subscribed.
• Tenable does not have the required permissions.
• Scans of the resource keep failing.

Tenable also closes the related vulnerability findings:

• If the resource still exists, the findings close as Closed – Resource disabled.
• If the resource was deleted, the findings close as Closed – Resource deleted, as before.

When Scan Data Is Deleted

The deletion point depends on your environment and license.

Impact and Value

• Accurate findings — Old scan data can show outdated findings for resources that Tenable does not scan anymore. After this change, your dashboard shows only current security posture information.
• No action required — If Tenable scans your resources regularly, your scan data and open findings stay the same.

What’s Changing?

The following GraphQL API fields were deprecated and will be removed:

Fields

Motivation and Value

Ensure consistency and alignment across Cloud Exposure API fields and filters.
The generically named scan-related fields for Vulnerability Management have been renamed to ensure they are not confused with Data or Network scans.

Backward Compatibility (Requires Action)

If you use the Cloud Exposure GraphQL API, your workflow may be affected by these changes.

What's Changing?

When you enable Automatically update folder structure, Cloud Exposure mirrors the folder structure of your cloud environment.

Before this change, Tenable did not sync some moves in the Console. This happened when an account or subfolder moved to a different parent folder in your cloud environment, and the previous parent had a custom policy or exclusion. This kept the findings from being deleted, but the account stayed in its old folder, and your folder structure in Tenable no longer matched your cloud environment.

Now, Tenable syncs these moves. The account or subfolder moves to its new parent folder, and the custom policies and exclusions on the previous parent stop applying to it.

For example, Account A moves from Folder X to Folder Y in your cloud environment. Folder X has a custom policy.

• Before this change — Account A stayed in Folder X in the Console and kept the custom policy findings.

• Now — Account A moves to Folder Y. The custom policy on Folder X no longer applies to Account A, so Tenable deletes its findings on Account A.

  

Impact and Value

• Accurate folder structure — Your accounts and subfolders follow your cloud folder structure. The folders in the Console match your cloud environment.
• Custom policy findings — A custom policy on the previous parent folder no longer applies to the moved account or subfolder. Tenable deletes the findings of that policy on the moved resources.
• Exclusion findings — An exclusion on the previous parent folder no longer applies after the move. Findings that the exclusion ignored reopen. Findings that the exclusion changed return to their original severity.

Backward Compatibility

You do not need to change your configuration. This change does not affect you if:

• Automatically update folder structure is turned off.
• Your parent folders do not have custom policies or exclusions.

Tenable still blocks moves that break an existing setup. An account stays in its current folder if one of the following items on that account uses an integration, policy, or role defined outside its new folder:

• Automation
• Scheduled report
• Custom compliance
• Role assignment
• JIT eligibility

Planned Release Date: November 1, 2026

What's Changing?

Cloud Exposure will start to delete stale self-managed clusters on November 1, 2026.

A self-managed cluster follows this lifecycle:

• If the cluster does not report for 24 hours, the countdown to deletion starts. The cluster stays in Inventory, and its findings stay open.
• If the cluster does not report for the full retention period, it is deleted from the Console, and its findings are closed. The default retention period is 30 days.
• If the cluster reports again within 30 days after deletion, Tenable restores it with its configuration and history. Tenable reopens its findings.
• 30 days after deletion, Tenable deletes the cluster permanently. You cannot restore it.

You can change the retention period, or disable it for each scope. Go to Settings > Security > Workload > Kubernetes Cluster. For the steps, see Configure Self-Managed Kubernetes Cluster Retention. For more about each stage, see Cluster Lifecycle.

Actions to Take

Starting on November 1, 2026, self-managed clusters will automatically be deleted by Tenable if they have not reported for the retention period. No configuration changes are required. Until then, review your self-managed clusters to confirm if they are stale.

To prepare, do these steps:

1. In Explore > Compute > Kubernetes Cluster, review the Cluster Sync Time column. Look for clusters with a time older than 30 days.
2. For each of these clusters, decide what to do:
   • If you decommissioned the cluster, you do not need to do anything. Tenable will delete it.
   • If you want to keep the cluster, reconnect its sensor so that it reports before November 1, 2026.
   • If the cluster should stay offline for a long time, increase the retention period, or disable it for the clusters scope.

Motivation and Value

• Cleaner inventory. Tenable will delete decommissioned clusters from your inventory. You will not see old clusters or their open findings.
• Time to reconnect — The 30-day default gives a cluster that is offline for a short time enough time to report again. A deleted cluster stays restorable for 30 more days.
• Control for each scope — You can use a short retention period for test clusters. You can use a long period, or turn off retention, for clusters that go offline for maintenance.

Planned Release Date: October 6, 2026

What's Changing?

Scan Exclusions is being moved from Early Availability to General Availability. Scan Exclusions is a tab on Settings > Cloud Exposure > Workload alongside Virtual Machine, Virtual Machine Image, and Container Registry.

Scan Exclusions uses the same query builder as Explorer. Use it to define which virtual machines, virtual machine images, and container images the scans skip.

At the same time, the Virtual Machine Exclusion Tags and Virtual Machine Image Exclusion Tags tabs are being removed. All scan exclusions, for every workload resource type, are now created and managed from Scan Exclusions.

Impact and Value

• Query-based rules — Scan Exclusions lets you build a query against any
  resource attribute like region, account ID, resource name, tags, and more,
  allowing for flexibility and scalability.
• No tagging prerequisite — Previously, excluding a virtual machine or
  image from scanning required tagging it in your cloud provider first. In Scan Exclusions, you can define exclusions without changing tags in your cloud provider.
• Container registry exclusions — Tag-based exclusion could not cover container registries. However, Scan Exclusions lets you exclude container images in the same way as virtual machines.
• Dynamic queries — You define an exclusion one time as a query. Each new resource that matches the query is excluded from the next scan cycle.
• One place for all exclusions — View, edit, enable, disable, and delete all exclusions in one table. A preview shows the resources that each exclusion targets.

Backward Compatibility

You do not need to take action. Your existing exclusions are migrated to Scan Exclusions and will continue to work.

After the migration, you can review your exclusions in Scan Exclusions, and create, edit, or remove exclusions.

What's Changing?

Cloud Exposure is expanding its secret detection engine with over 150 additional secret data types that cover secret keys, tokens, and sensitive URLs. For the full, updated list of supported secret data types, see Secret Data Types.

Impact and Value

• Broader coverage — The engine detects and classifies more secret types, catching exposures that previously went unrecognized and reducing blind spots in your secret exposure posture.
• More accurate findings — Refined detection logic means some existing findings may be reclassified or closed as false positives. This update fixes false positives, rather than just adds new detections.
• Finer-grained control — You can control the new secret types individually via data type management, classification exclusions, or custom policies.

Backward Compatibility

The detection logic will update automatically on the release date. No configuration changes are required.

The new secret data types will not be added to classification exclusions or custom policies that are configured for specific data types. They will only be added automatically to exclusions or policies configured for Any data type, the Secret data category, or the relevant data sensitivity level. Make sure to review your configurations after August 30 to confirm the new data types are covered as expected.

What's Changing?

Cloud Exposure is releasing an update to its Software Composition Analysis (SCA) detection engine.

Detection capabilities are being expanded to better identify unpatched and zero-day vulnerabilities across open-source components and third-party dependencies. The software ecosystems most impacted by this update are Java (Maven), PHP (Composer), and Node.js (npm), which represent the vast majority of newly reported findings.

The detection logic will update automatically on the release date. No configuration changes are required.

Impact and Value

• Increased vulnerability volume — As a result of this broader coverage, you may notice an increase in the total number of detected vulnerabilities in your application repositories and builds.
• Improved visibility — This reduction in blind spots will give your security and development teams a more complete picture of unpatched risk across your software supply chain.

What's Changing?

Tenable is changing the property names and structure of the Cloud and Code finding data delivered through your SIEM integration. If you consume this feed to build detections, dashboards, or reports, review the changes below and update your property mappings before the release date.

Cloud Findings

The following properties are removed from Cloud finding data.

The following properties are renamed in Cloud finding data.

The following properties change behavior in Cloud finding data.

Code Findings

The following properties are removed from Code finding data.

The following properties are renamed in Code finding data.

Code finding data adds two new properties.

• accountId — Identifier of the account (repository) the IaC resource belongs to.
• accountPath — Path of the account (repository) in your account hierarchy.

Backward Compatibility (Requires Action)

If your SIEM integration, saved queries, or dashboards reference any of the removed or renamed properties described in SIEM Integration Finding Property Changes (August 30, 2026) or SIEM Integration Finding Property Changes (August 30, 2026), update them before August 16, 2026. Queries and mappings that reference the old property names stop returning data for those properties after this date.

Motivation and Value

Tenable is aligning the Cloud and Code finding schemas so both feeds use the same property names and structure for shared concepts. A single provider property replaces cloudProvider and platform, and a single statusUpdateTime property replaces a key that used to change name depending on status. This reduces the mapping logic your SIEM needs to maintain across Cloud and Code data.

jiraIssueLinks and serviceNowIncidentUrls are removed because they duplicate ticketLinks, which already lists the same Jira and ServiceNow links in one place.

Capping comments and vulnerabilities keeps large findings from producing oversized payloads, which lowers ingestion cost and latency in your SIEM.

What's Changing?

Cloud Exposure is streamlining Windows vulnerability detection to report findings at the application level rather than for individual .exe and .dll component files within an installed application's directory.

Component files (.exe/.dll) within an installed application cannot be patched individually, so resolving them requires updating the parent application. Previously, reporting these components created redundant, non-actionable findings.

Impact and Value

• Noise reduction — This fix eliminates duplicate alerts while maintaining complete vulnerability coverage. Expect a reduction in your overall vulnerability instance count across the dashboard and the Vulnerability Instances API, as well as fewer duplicate sub-components and internal libraries listed on the Software page.
• Historical data handling — Previously reported component-level findings will drop off naturally to ensure reporting accuracy without falsely appearing as resolved.
• No change to unregistered files — Standalone executables and DLLs not tied to a registered installation will continue to be reported as before.

What's Changing?

Tenable is resolving an issue that causes a subset of Infrastructure as Code (IaC) policies to stop evaluating certain IaC resources. While affected, these policies do not open new findings or close existing findings.

The fix will be applied automatically by Cloud Exposure. No configuration changes to policies, exclusions, or workflows are required.

Impact and Value

• Accurate findings — IaC findings for the affected policies will now reflect the current state of your IaC resources.

What's Changing?

Tenable is moving the following four trend widgets on the Cloud Exposure Overview dashboard to a query-based model, the same approach used in Explorer.

• Findings By Severity
• Findings Trend
• Findings MTTR
• Resolved Findings,

Any custom dashboard that includes one of these widgets is migrated the same way.

This change has two parts:

• Widgets run on a built-in or custom query. Every account gets a built-in All Findings monitored query that powers the Overview dashboard. If you built a custom dashboard with saved filters on one of these widgets, that configuration migrates automatically into its own custom query, named {Finding type} | {Categories (up to 3)} | {Policy count ("X policies")}, so your filtered view keeps working exactly as it did before.
• The Category and Policy on-the-fly filters move into the query. Today you can toggle the Category and Policy filters live while viewing a widget. After this change, those two filters are no longer available as live toggles. All other on-the-fly filters are unaffected. To filter by Category or Policy, add that condition to the widget's underlying query when you edit it.

Impact and Value

Moving these widgets to a query-based model brings them in line with Explorer, so the logic behind a trend widget works the same way it does there. No customer action is required. Existing custom dashboards and their saved filters carry over automatically as custom metrics, and you will see these new custom queries listed in All Queries.

What to Expect

• Your Overview dashboard continues to show the same four widgets, now backed by the built-in All Findings metric.
• Any custom dashboard using these widgets keeps its existing filtered view, now backed by an automatically created custom metric.
• If you filter by Category or Policy today, you will not see those as live toggle options after the change. Edit the widget to set that filter in its query instead.

What's Changing?

Tenable is changing how container images are assigned to cloud accounts in Cloud Exposure to make vulnerability visibility more accurate and predictable. When you use the scope filter, every account now sees the container images it actually runs, not only the images it owns. You can use the account filter to filter container image ownership within the vulnerability table.

This change has two parts:

• New Container Registries scope for public and unsynced images.
  • Container images pulled from registries you have not synced to Cloud Exposure (for example, docker.io, quay.io, or public GHCR) now consolidate under a single account owner named Container Registries, a new high-level scope you can select in the account and scope filters.
  • Previously, the same public image could appear as a separate entity in each cloud account that pulled it, or its account ownership could switch between accounts across scans as digests rotated. Both behaviors were confusing and inaccurate.
• Shared images visible to every account that runs them.
  • If your organization has multiple cloud accounts that pull the same container image, each account now sees that image in its own inventory and vulnerability views. For example, if your production and non-production AWS accounts both run pods that pull docker.io/library/nginx, previously only the account that scanned the image first saw it.
  • Now both accounts see the image under their own scope, with its vulnerabilities, packages, and risks tied to the workloads in each account.

Impact Summary

These changes affect dashboards, findings pages, and scheduled reports. No action is required. The changes apply automatically.

• Existing filters and dashboards that grouped container images by account show a new Container Registries account for unsynced images.
• Container image entity counts for specific cloud accounts drop, and the Container Registries count grows to match.
• Account ownership for public images no longer switches between accounts after scans.
• Vulnerability counts on account dashboards can increase, sometimes materially. These counts do not represent new vulnerabilities. They represent exposure that was always present but was previously invisible to the consuming account.
• The Vulnerabilities, Software, and Malicious Files pages show entries for shared images under every account that consumes them.
• Scheduled reports are affected because they are exported for a predefined scope. A report now includes vulnerabilities for the container images used within the selected scope, including images owned by other accounts but used within that scope.

What’s Changing?

Tenable has updated its secret-detection logic to reduce false positives and catch secrets it previously missed.

The logic is updated automatically. No configuration changes are required. Existing workflows such as policy management, exclusions management, and the findings lifecycle remain unchanged.

Impact and Value

• Closed findings — With fewer false positives, findings more reliably represent actual exposed secrets, reducing time spent investigating noise.
• Improved detection coverage — Secrets that were previously missed are now detected.

Affected Policies

• AWS resource tags are exposing secrets
• AWS EC2 Instance is exposing secrets
• AWS CloudFormation Stack is exposing secrets
• AWS ECS Task Definition is exposing secrets
• AWS Lambda Function is exposing secrets
• GCP resource labels are exposing secrets
• GCP VM Instance is exposing secrets
• GCP App Engine Service is exposing secrets
• GCP Cloud Function is exposing secrets
• GCP Cloud Run Service is exposing secrets
• Azure resource tags are exposing secrets
• Azure Logic App is exposing secrets

What’s Changing?

Tenable has updated the logic for the Unusual user agent client used threat rule in Cloud Exposure to reduce false positives and deliver higher-fidelity detections.

• Seamless integration — The updated logic replaces the previous logic automatically. You do not need to perform any manual configuration changes to receive this update.

Impact and Value

• High-fidelity detections — The rule now generates high-fidelity detections, so each result represents a distinct, high-confidence threat that your team can act on with greater trust.
• More reliable security data — With higher-fidelity results, your security findings provide a more dependable basis for investigation and response.

What’s Changing?

Tenable has updated the detection logic for suspected malicious files in Cloud Exposure to reduce false positives and deliver higher-fidelity detections.

• Seamless integration — The updated logic applies automatically. You do not need to perform any manual configuration changes to receive this update.

Impact and Value

• High-fidelity detections — With fewer false positives, suspected malicious file findings more reliably represent genuine threats that your team can act on with confidence.
• More reliable security data — Higher-fidelity results provide a more dependable basis for investigation and response.

Status and Transition

• Current status — Available Now in Beta Mode within Tenable Vulnerability Management.
• Transition plan — The original VPR and the enhanced VPR (Beta) will coexist for a transition period.
• Planned deprecation — Full transition to the enhanced VPR is planned for July 1, 2026.

What's Changing?

Tenable has released significant enhancements to the patented Vulnerability Priority Rating (VPR) to improve prioritization accuracy.

• Enhanced VPR score — The updated VPR is now twice as efficient as the original version at identifying CVEs that are either actively being exploited in the wild or are predicted to be exploited in the near term.
• Increased precision — The enhanced VPR further refines focus, helping your teams concentrate on just 1.6% of vulnerabilities that represent actual risk (down from 3% with the original VPR).
• New contextual metadata — New metadata provides crucial context, helping you understand if a vulnerability is being targeted. This information is visible in the Threat Factors area of the vulnerability profile.

Impact and Value

• Improved focus — You gain greater risk reduction by focusing efforts on the most critical set of vulnerabilities that require immediate action, increasing team efficiency.
• Beta functionality — During the Beta phase, the new score is visible only and displayed alongside the original VPR. It does not affect vulnerability severity calculations, finding creation, or configured workflows.
• Preparation — The coexistence period allows you to compare the two scores and gradually adapt your internal prioritization processes before the full transition in July 1, 2026.

For more details, see the documentation.

What's Changing?

Tenable has begun a global rollout of Non-Root Volume Scanning for virtual machines.

• Automatic enablement — Your environment will be updated automatically in the coming weeks. No manual configuration is needed.
• Billing update — These scans will be billed under a new Data Disks category specific to each cloud provider.

Motivation and Value

Expanding scanning from the root volume to non-root volumes is a critical step in closing security gaps. Key benefits include:

• Eliminating blind spots — Attackers often hide malicious binaries or exploit outdated libraries within secondary volumes to bypass basic "OS-only" scans.
• Securing the application stack — Most modern applications and databases are installed on separate disks to prevent root partition overflow. Scanning these ensures your software stack is fully monitored.
• Preventing lateral movement — Identifying vulnerabilities in non-root volumes helps prevent attackers from gaining a foothold and moving laterally across your network.
• Ensuring compliance — This update helps satisfy regulatory frameworks (like PCI-DSS or SOC2) that require a comprehensive assessment of the entire attack surface.

FAQ

How will this feature be licensed?

The non-root disks will be categorized under a new Data Disks category for each cloud provider (AWS, Azure, GCP, and OCI) on the Licensing page.

Note: During the initial rollout phase, Azure Virtual Machine disks attached to Scale Sets will not incur any scanning charges

What is the maximum disk size and number of volumes supported?

• Current maximum disk size — 600GB per individual disk
• Current # of volumes supported — Up to four disks per resource (including the root volume).

How can I view the scan status for a specific virtual machine?

To view the status of all attached disks for a specific VM:
1. Navigate to the profile page for the virtual machine.
2. In the the Overview tab, view the Disks/Volumes table.

Can I disable non-root scanning?

Yes. You can manage this feature under Settings > Security > Workload > Extended Disk Scanning.

Note: This setting is enabled by default.

How does the scan logic work, and what does the "Partial" status indicate?

The logic follows an all-or-nothing approach for data disks: Tenable scans either:

• The root volume only
• The root volume, plus all eligible non-root volumes.

Tenable does not perform partial scans of the non-root set.

If the root volume is scanned but the non-root volumes are skipped, the virtual machine scan status will display as Partial.

Example Use Case:

• Scan Status — Partial
• Reason — At least one attached disk exceeds the 600GB size limit.

What's Changing?

Currently, there are five generic data types mapped to the Secrets category:

• Generic Password
• Runtime Secret
• Secret Key
• Sensitive URL
• Token

Starting May 10, these data types will be separated into 280+ individual data types. For example, the Token data type will be split into over 160 data types, such as AWS Session Token and Confluent Access Token.

Value

• Improved visibility — Classification of a Secret data type will be more accurate, helping you pinpoint its location, and how to deal with the risk.
• More accurate sensitivity levels — Because there are individual data types, the associated severity level will be more accurate for each type.
• Granular control — You can now apply Exclusions and configure custom policies for each individual Secret data type, giving you precise control over your security policies.

Impact

• Risk recalculation — Findings will be recalculated during the next scheduled scan following the update.
• Workload Data Scan — Some of the new data types will have a sensitivity level lower than Restricted which might result in a reduction of the overall risk of the resource following the next scheduled scan result.

What's Changing?

Tenable is unifying the naming convention for policies identifying network-based public and wide-inbound internet exposure.

These policies will be standardized to the following format:

• {resource_name} is exposed to the internet

Policy Name Changes

The following table details the full list of policy name changes:

Motivation and Value

• Standardize policy naming to ensure consistency and accuracy across policies and findings.
• Streamline how risk is communicated by focusing on potential exposure.

Backward Compatibility

This update is a display-only change to policy titles and does not require any manual adjustments to your environment.

• Automations and queries — All existing automations and saved queries will continue to function normally. Since the change applies only to the display name of the existing Policy ID, your workflows will automatically reflect the new naming.
• GraphQL API — There is no impact on API usage. Finding queries leverage PolicyIds or Types filters, neither of which are affected by this update.

What's Changing?

Tenable is implementing a breaking change to the GraphQL API by consolidating account-related queries into a single entry point. The legacy, provider-specific queries for AWS, Azure, and GCP are being replaced by the consolidated Accounts query.

Deprecated Queries

The following top-level queries will be removed from the schema:

Action Required

You must update any automation scripts, integrations, or custom reports that rely on the legacy queries listed above.

To maintain functionality, migrate your requests to the Accounts query. For detailed implementation steps and cloud-specific examples, see the Account API documentation.

What’s Changing?

Tenable is updating the malware detection logic within Cloud Exposure to provide more accurate and comprehensive coverage of modern threats.

• Updated detection logic — This enhancement improves how Tenable identifies malware signatures and behaviors within your cloud workloads. The updated logic ensures that your security data reflects the most current threat environment.
• Seamless integration — The new detection engine replaces the legacy logic automatically. You do not need to perform manual configuration changes to receive these updates.

Impact and Value

• Increased detection precision — The updated logic improves the identification of malware, ensuring your security findings are based on the most refined detection methods available.
• Reliable remediation data — By refining how malware is identified, Tenable provides you with more accurate information to support your incident response and remediation efforts.

What's Changing?

Currently, when data scanning is disabled for a resource, the most recent scan results remain in the Cloud Exposure console indefinitely. This can lead to outdated, misleading, and irrelevant data.

Starting April 12, Tenable is updating this behavior to ensure your environment reflects only active monitoring.

New Behavior

• Data retention — Once scanning is disabled for a resource, classification results older than 30 days will be automatically cleared from the console and API.
• Platform transparency — After 30 days, classification results will no longer be available for disabled resources via the resource Data tab, related columns, or API queries.
• Risk recalculation — Existing finding severities will be recalculated, and findings triggered by data policies (custom and built-in) will be closed.

Impact and Value

This update ensures your security posture is based on current, actionable data rather than stale, unmonitored results.

• Improved risk assessment — Risk levels and alerts will be tied strictly to resources where data is currently being monitored and billed.
• Accurate data in console — Ensure your environment remains focused on active scanning configurations and current data privacy preferences.

What's Changing?

Cloud Exposure is upgrading how internet exposure analysis for cloud resources is determined. Currently, internet exposure is determined by static analysis of cloud resource configurations that flag resources appearing internet-facing. With Network Scanner (introduced December 2025), exposure is dynamically validated by attempting to connect to flagged resources to confirm actual reachability.

With this update, the scanner becomes part of network evaluation and will impact how public internet-facing exposure is being calculated.

Key changes include:

• Verified direct internet exposure — For supported direct resources (such as EC2, RDS, and Redshift), a resource will only be classified as Public (internet-facing) if the Network Scanner successfully verifies reachability and creates a Network Endpoint.
• Findings severity — Verified internet exposure is now a factor in determining the severity of network-related findings. By using confirmed reachability rather than configuration alone, noise is reduced and risk levels of findings reflect actual exposure. As a result, the severity of affected findings may be either decreased or increased, providing a more precise risk assessment.
• Fallback logic — Resources that are indirectly exposed, such as those behind load balancers or API gateways, will continue to use static configuration analysis for exposure until scanner support is added in the upcoming months.

For more information, see Network Exposure.

How to See Whether Finding Is Affected

To identify affected direct resources, look for the The [Resource] exposes X network endpoints line within the finding's profile. This indicates that the Network Scanner has dynamically verified actual reachability, confirming the finding is based on a real-world connection rather than just static configuration.

Motivation and Value

This shift moves theoretical risk to validated exposure.

• Eliminate noise — Prevents security teams from chasing internet-facing findings for resources that are actually protected by external firewalls, proxies, or other resources not included in network evaluation.
• Prioritize real threats — Ensure high-severity alerts and risk scores focus on assets that an attacker can actually reach from the internet.
• Toxic combinations — Confirm whether assets such as critical vulnerabilities, overprivileged identities, or sensitive data are truly Public, allowing you to prioritize the most dangerous risks across your environment.

What to Expect

The implementation of verified reachability may change the severity of your findings. For supported resources, risk levels will now be determined by confirmed scanner results rather than static configuration analysis alone.

This change ensures that your security posture accurately reflects real-world exposure, though you may notice adjustments to the severity of existing findings as they align with verified reachability data.

To ensure the scanner can verify your reachable resources and accurately reflect your risk, ensure your firewall/WAF rules allow traffic from the Scanner origin IP addresses.

Affected Policies

The following tables detail which specific policies are impacted by the transition to verified internet exposure.

Provider-Specific Policies

Workload Protection Policies

What's Changing?

Effective April 5, 2026, Tenable is deprecating exclusion annotations for findings in IaC security.

Tenable is making this change to ensure that security teams have full visibility of all excluded findings. When exclusions are defined in IaC, they can be applied without the security team's knowledge.

Impact

If you currently use exclusion annotations to manage IaC findings, you must transition to an alternative way to exclude findings. After April 5, 2026, Tenable will no longer recognize these annotations.

What's Changing?

Tenable is transitioning Amazon Machine Image (AMI) scanning from a complimentary service to a billable service.

Impact and Value

• Tenable automatically continues scanning your AMIs. You do not need to take action to maintain coverage.
• Scanned EC2 Images count toward your licensed resource usage.
• You can monitor your current usage at any time on the Licensing page.
• You can manage your scanning preferences by navigating to Settings > Cloud Exposure > Workload > Virtual Machine Image.

What's Changing?

On March 3, 2026, Tenable is updating the method for querying unmanaged Kubernetes clusters within the Inventory API. These specific clusters will no longer be available via Cloud provider resource queries. Instead, you must access them through the Entities query.

This update removes provider-specific prefixes (for example, Aws) from the filter and casting types, standardizing how you interact with unmanaged Kubernetes clusters across different environments.

Action Required

You must update your GraphQL API queries to reflect the new entity naming convention before the release date. If your existing integrations or scripts rely on provider-specific types, such as AwsUnmanagedKubernetesCluster, you must update them to the generic UnmanagedKubernetesCluster type.

Impact and Value

This change simplifies the GraphQL schema and improves consistency for customers managing multi-cloud or hybrid environments. By removing provider-specific prefixes, Tenable provides a unified way to query unmanaged Kubernetes resources, reducing the complexity of your API implementations.

Change Details

The following table outlines the specific syntax changes required for unmanaged Kubernetes cluster queries:

API Query Example Comparison

Use the following examples to compare the legacy syntax with the required new structure for unmanaged clusters.

Legacy Query (No longer supported after March 3)

query 
{
  Entities(filter:{Types:[AwsUnmanagedKubernetesCluster]})
    {
      nodes
      {
        __typename
        Name
        Id
        Provider
        ... on AwsUnmanagedKubernetesCluster {
            Region
        }
      }
    }
}

New Query (Required)

This query uses the standardized entity type. To isolate a specific provider, add the Providers argument to your filter.

query
{
  Entities(filter:{Types:[UnmanagedKubernetesCluster], Providers:[AWS]})
    {
      nodes
      {
        __typename
        Name
        Id
        Provider
        ... on UnmanagedKubernetesCluster {
            SyncTime
        }
      }
    }
}

Status and Transition

• Current status — Available now for all AWS Cloud Workload Protection (CWP) users.
• Transition plan — AWS cloud integrations will begin reflecting the new scanning logic.
• Full implementation — The transition to AMI scanning as a default setting will be completed by January 25, 2026.

What's Changing?

Tenable is standardizing cloud security coverage by making AMI (Amazon Machine Image) scanning a default requirement for all AWS Cloud Workload Protection (CWP) users. This move ensures a comprehensive security baseline across the entire resource lifecycle.

• Consistency — While every CWP resource is already scanned by default (e.g., virtual machines), virtual machine images will now receive the same configuration to ensure comprehensive coverage.
• Permissions handling — Virtual machine image permissions are requested by default during the current CWP onboarding.
• Status update — For legacy customers or those with modified policies, the virtual machine image status will change from Disabled to Not Supported (indicating missing permissions).

Impact and Value

• Negligible cost compared to security value — Enabling AMI scanning by default broadens your security posture with minimal impact on resources. These scans are expected to incur negligible costs within your cloud environment while providing critical visibility into your image library.
• Comprehensive security baseline with “Shift-left” — By treating AMI scanning as a default requirement, Tenable ensures that all preconfigured image templates are evaluated for vulnerabilities before they are used to launch new instances. This prevents security flaws from being replicated across your entire environment.

Preparation

• Review permissions — Ensure your AWS IAM policies include the necessary permissions to scan AMIs to avoid the "Not Supported" status.
• Verify transition — Monitor your AWS integrations as they transition to the new logic ahead of the January 25th deadline.