Nutanix 7.6: security stops being a checklist and becomes part of the platform

Between 27 July and 5 August 2026, Nutanix shipped ten coordinated releases. AOS 7.6, Prism Central pc.7.6, AHV 11.2, NGT 4.6, NCC 6.0, MSP 3.1.0.0, Flow Network Security 7.6.0, Flow Virtual Networking 7.6.0 and Witness Service 7.6. Move 6.3.0 and NDB 2.11 landed alongside.

We read every release note. The easy summary is the capacity numbers, and they are impressive.

The more interesting story is the security model. In 7.6, hardening stopped being a document you follow. It became behaviour the platform enforces on its own.

Note

Our own environment now runs 7.6 end to end. This post is the analysis we built while planning that upgrade, plus what we then verified directly on a running cluster.

This post covers the security story. Capacity, DR depth and the upgrade gates get their own follow-up, because they are a different conversation.

The short version

  • Hardening ships as a baseline, not a guide. CVM and Prism Central move to RHEL 9, aligned to the RHEL 9 STIG.
  • Administrative shell access is curated. The admin user gets a restricted menu instead of open bash.
  • Posture is a configuration object. Security Profiles come in Standard, Elevated and Strict tiers.
  • Drift is detected automatically. NCC 6.0 adds a security profile drift check.
  • Multi-tenancy became a real boundary. Projects now scope policies, categories and network security.
  • The patching was substantial. Nine CVE fixes in the microservices platform alone, one at CVSS 8.2.
  • But the defaults are softer than they look. Bash is still reachable after you enable the new controls. We tested this.
  • Bash is going away. Nutanix now says so in the login banner, not a roadmap slide.

The pattern worth noticing

Hardening a Nutanix estate used to mean the same exercise for every customer. Read the security guide. Apply the controls by hand. Hope nothing drifts before the next audit.

Every consultancy in this market built the same scripts to do it.

In 7.6, the whole loop ships in the box, across four components released in the same week:

Part of the problem What 7.6 ships Where
A hardened baseline RHEL 9 base OS, RHEL 9 STIG aligned AOS, Prism Central
Restricting admin access Secure Access, restricted shell AOS
Expressing posture as policy Security Profiles: Standard, Elevated, Strict Prism Central
Detecting drift Security profile drift check (A6229) NCC 6.0
Keeping components patched Nine CVE fixes, dependency rebases MSP 3.1.0.0, NGT 4.6

A baseline, a way to enforce it, a way to detect deviation, and a patching pass underneath. That is a security programme, not a feature list.

Secure Access: the CVM stops handing out a shell

This is the change with the most operational weight. It is also the one most likely to be misread, so it is worth the detail.

Secure Access (FEAT-17944) controls external SSH to the Controller VM. When external SSH is enabled, the admin user lands in the NuService Menu instead of an open bash session.

The menu is a restricted shell. From it you can run allow-listed commands, browse cluster logs, manage local LDAP authentication, and launch a bash session.

Finding it, because it is not where you would look

There is no page in Prism Central called Secure Access. This trips people up after upgrading.

The control is a per-cluster action:

output
Prism Central > application switcher > Infrastructure > Hardware > Clusters
  > tick the checkbox for the target cluster
  > More actions
  > Enable NuService Mode  |  Disable NuService Mode

Ticking the cluster checkbox first is the step people miss. The menu is state dependent, so you only ever see the option that applies to that cluster.

Two requirements are worth checking. The cluster must be registered with Prism Central. And the Security Guide gives the minimum as AOS 7.3 or later, even though the 7.6 release notes present Secure Access as new.

Important

Upgrading does not turn this on. A cluster upgraded to AOS 7.6 keeps the external SSH state it had before. It ends up disabled only if it was already disabled. If nothing appeared to change after your upgrade, this is why.

Once enabled, connecting as admin to a CVM gives you this:

output
============================
NuService  Menu:
============================
Option 1: Execute Commands
Option 2: Log Viewer
Option 3: Launch Admin Shell
Option 4: Configure Settings
Option 5: Help
Option X: Exit
============================

Note the target. This is ssh admin@<CVM_IP>, a Controller VM on a managed cluster. Not the Prism Central VM.

Nutanix is telling you bash is going away

The login banner on the way into that menu is the clearest statement of direction Nutanix has published:

output
******  IMPORTANT NOTICE - SSH / BASH SHELL ACCESS TRANSITION  ******

SSH access to Nutanix CVMs, AHV Hypervisors, Prism Central (PC),
and Nutanix Files will be disabled by default in the next release.

Custom scripts or automation that rely on Bash shell
access will not function following this transition.

REQUIRED ACTION:
  >> REVIEW all your custom scripts relying on bash shell access
  >> PLAN and MIGRATE to supported Nutanix v4 APIs

Refer to KB-20212 for details

That is not a roadmap slide. It is in the product today.

Every automation you own that shells into a CVM now has a deadline. "The next release" is a short runway. If you take one action from this post, inventory what depends on a CVM bash session.

What is actually on the allow-list

The Security Guide tells you to type help to see the available commands. It never publishes the list.

Here it is, from Execute Commands > CVM on a 7.6 cluster with NuService Mode enabled.

Full NuService allow-list (CVM target)
output
------ Nutanix Commands ------
  acli                                    install_host_package
  afs                                     intersight_info
  cerebro_cli                             lcm_cancel_updates
  change_ahv_hostname                     lcm_leader
  change_cvm_display_name                 lcm_node_recovery
  change_cvm_hostname                     lcm_upgrade_status
  change_cvm_vlan                         list_disks
  check_temporary_full_bash_access_expiration
                                          logbay
  cluster restart_genesis                 manage_bad_passwords.py
  cluster start                           manage_bootloader_fix
  cluster status                          manage_ipv6
  cluster stop                            manage_ovs
  collect_perf                            modify_firewall
  configure_restricted_access             ncc
  convert_cluster_status                  ncli
  cvm_shutdown                            network_segment_status --last_task
  disable_full_bash_access                nfs_ls
  ecli                                    nodetool -h 0 ring
  foundation_service                      nsx_t_manager -l
  genesis                                 nutanix_pulse_packet_helper.py
                                          panacea_cli
                                          progress_monitor_cli
                                          rolling_restart
                                          set_remote_diagnostics_status
                                          snapshot_tree_printer
                                          storcli64 /call/eall show
                                          stretch_params_printer
                                          upgrade_status
                                          zeus_config_printer

------ System Commands ------
  arping          iptables --check        nslookup
  chronyc tracking  iptables --list       rsync
  date            iptables --list-rules   sar
  df              last                    scp
  dmesg           md5sum                  smartctl
  iptables -C / -L / -S

Two design details say more about the engineering than the feature description does.

Some entries are pinned to specific arguments. iptables is allow-listed only in its read-only forms: -C, -L, -S, --check, --list, --list-rules. You can inspect the firewall, not modify it.

The same pattern applies to nodetool -h 0 ring, storcli64 /call/eall show, network_segment_status --last_task, nsx_t_manager -l and chronyc tracking. That is a considered allow-list, not a naive list of binaries.

But the list is powerful, not low privilege. acli, ncli, ecli, cerebro_cli and genesis are all present. So is cluster stop.

Anyone in this menu can enumerate and manipulate VMs, inspect cluster configuration, and stop the cluster. Sub-commands are not filtered. ncli vm list runs exactly as it would in bash.

So here is the honest description. This is not privilege reduction. It removes the arbitrary surface: no editing system files, no installing packages, no unapproved binaries, and an audit record for every interaction.

For "can you evidence what administrators did on this host", that is the whole point. For "can an administrator take this cluster down", nothing changed.

What it does and does not close

This is the part to read carefully before writing it into a control narrative. It is also the part we most wanted to test rather than take on trust.

Under default Secure Access, bash is still reachable by two routes. We confirmed both on a 7.6 cluster with NuService Mode enabled:

  • Option 3, Launch Admin Shell opens a bash session immediately. No token exchange.
  • The nutanix user is untouched. ssh nutanix@<CVM_IP> gives a normal bash prompt. No menu, no restriction.

The other options behave as documented. Log Viewer opens a file browser for cluster logs. Configure Settings exposes the LDAP sub-menu.

So the default posture is better auditing and a curated command surface. It is not the removal of interactive shell access.

Enabling NuService Mode and reporting "shell access is now restricted" would be wrong on both counts.

Tip

While you are here, check the password on the nutanix account. It keeps full bash over SSH under default Secure Access. If it is still the factory default, the control you just enabled has an open door beside it.

Closing the gap: Support-only Login

Closing that gap is a separate, deliberate step.

Once Support-only Login is activated, no bash session on a CVM can start without a token exchange with Nutanix Support. Access is granted for a fixed 72 hour window. The nutanix user loses its bash session over SSH too.

That is administrator and vendor access with an expiry and an audit trail. It used to be a policy promise. Now it is a technical control.

You activate it by running configure_restricted_access from Execute Commands, then confirming with an uppercase YES.

Warning

Support-only Login is irreversible. After activation, the token exchange requirement cannot be removed, even if external SSH is disabled and re-enabled. Before activating it in production, migrate any automation that needs a CVM bash session to the v4 APIs (KB-20212). Inventory first, then close the door.

Alongside it, Enhanced CVM Security (FEAT-18000) further restricts data access inside the CVM. It applies to fresh and upgraded clusters, and now covers NC2.

A hardened base OS, not a hardening guide

The CVM and Prism Central VM base OS moves to RHEL 9 (FEAT-15640, FEAT-18534). The release notes state this aligns the CVM with the RHEL 9 STIG.

The significance is what it removes from a project plan. STIG alignment of the base OS used to be either an assumption nobody validated, or a hardening exercise a consultant performed by hand.

Shipping it as the default changes the conversation. It moves from "can we harden this" to "here is the baseline, what does your policy add on top".

Security Profiles: posture as a configuration object

Prism Central pc.7.6 introduces Security Profiles (FEAT-17570). Three tiers: Standard, Elevated and Strict, applied to AOS and AHV.

This is the piece that was missing. A hardened baseline is useful, but estates are not uniform. A development cluster and a cluster holding regulated workloads should not carry the same posture.

Until now, that difference lived in a spreadsheet. Expressing it as a profile makes posture a property of the cluster: something you can set, report on and compare.

Prism Central also gains:

  • External key manager configuration from the web console (ENG-819354), plus further KMS enhancements (FEAT-18453)
  • A security dashboard extended to NC2 clusters (FEAT-17587)
  • Increased concurrent login sessions (FEAT-18031)

Identity became a real tenancy boundary

The RBAC work in pc.7.6 is easy to miss because it is presented as a management feature. It is a security boundary.

Projects (FEAT-17277, FEAT-17626) are now the enterprise multi-tenancy construct, with project-scoped categories (FEAT-17133, FEAT-17170) and automatic migration of existing entities into a Default Project (FEAT-17173).

The reason this matters is that the boundary now extends into the network security layer. Flow Network Security gained Projects support (FEAT-17979), so policies, address groups, service groups and entity groups all carry project-scoped ownership and RBAC. Flow Virtual Networking did the same for VPCs, subnets, gateways, route tables, floating IPs and BGP sessions (FEAT-17271).

For anyone running a shared platform across business units, or an MSP running multiple clients on one estate, that is the difference between a naming convention and an enforced boundary.

On authentication, the tested identity providers are ADFS, Microsoft Entra ID, Okta, PingOne, Shibboleth and Keycloak. Prism Central IAM also supports CAC client authentication, which needs port 9441 open.

One fixed bug deserves a mention because it is the kind that undermines a tenancy claim. NET-16367: an RBAC user with scoped VPC access could see Flow Network Security policies outside their assigned VPC scope. If you have been relying on VPC-scoped RBAC for separation, that is worth knowing was leaking.

Note

Two IAM limits to design around. Prism Central can hit out-of-memory errors past roughly 1,000 authorization policies (ENG-943775). And uploading a new ECDSA certificate can stall services (ENG-782322), with NCC checks and Nuclei authentication failing on ECDSA certs until they are re-uploaded (ENG-765604).

Flow Network Security 7.6: microsegmentation a firewall team recognises

The zero trust story got a serious overhaul. The changes read like they came from people who have actually migrated a perimeter firewall estate.

  • Rule-centric policy model (FEAT-17760). Each rule independently defines source, destination, traffic config, action and scope, with no dependency on application constructs. It also brings rule prioritisation and explicit deny rules, which is what makes a conventional firewall ruleset expressible at all.
  • FQDN based policies (FEAT-17727). Domain names as source or destination, resolved by DNS, instead of chasing IP changes by hand.
  • Kubernetes enhancements (FEAT-17783). Single step agent install, automatic service IP and port detection, ingress and load balancer integration, egress gateway with dedicated Pod IPs.
  • Security Analytics and Intelligence (FEAT-17766). Flows and Rules dashboards covering policy usage, with flow visibility retained for up to 90 days. This is the evidence layer for an audit conversation.
  • Scale (FEAT-17845). Up to 100,000 rules, 500 rules per application policy, 40,000 address groups.

The 90 day retention is the detail worth holding on to. "Show me what talked to this workload last quarter" is a question that comes up in incident response and in audit, and it now has an answer that does not involve a separate collector.

The patching pass nobody reads

Release notes bury this, but 7.6 carried a substantial dependency and CVE cleanup. For anyone maintaining a patch-hygiene argument with an auditor, this is the useful part.

MSP 3.1.0.0, the microservices platform underneath Prism Central services, is close to a pure security release. Nine CVE fixes, including:

Issue Severity
Harbor CVEs (CVE-2024-45337, CVE-2025-22868, CVE-2025-22869, CVE-2025-30204, CVE-2024-45339, CVE-2023-39325) High, up to CVSS 8.2
Linux kernel privilege escalation (CVE-2026-43500, CVE-2026-43284, CVE-2026-46300) CVSS 7.8
ICMP timestamp disclosure (ENG-723854) Low

NGT 4.6 rebased its runtime to Python 3.11.15 and OpenSSL 3.0.19 to clear multiple CVEs (ENG-777248). Since NGT runs inside guest VMs, this one touches the largest surface in most estates.

NCC 6.0 resolved a medium risk libcurl issue leaking cross-proxy Digest authentication state (ENG-939074).

AOS 7.6 cleared false-positive scanner findings caused by ssh-rsa and ssh-rsa-cert-v01 appearing in the SSH crypto policy (ENG-819243). Not a vulnerability, but anyone who has argued with a scanner report will appreciate it.

Certificates stop expiring quietly

Two fixes address a failure mode that generates real outages.

NGT server certificates now refresh automatically when they fall under 100 days to expiry (ENG-645332). Silent certificate expiry is one of those faults that looks like a total service failure and takes hours to diagnose.

Prism Central also fixed SAML login failing when multiple TLS certificates were present (ENG-792636), and certificate and CA chain import validation errors (ENG-462072).

Data protection, and sharing logs without leaking them

Two encryption fixes are worth flagging. Both are the kind of problem that quietly undermines a compliance position:

  • ENG-909674: Native KMS remote was unavailable for data at rest encryption in an otherwise valid configuration.
  • ENG-933985: vTPM enabled AHV VMs under synchronous replication or Metro failed to power on.

Less obvious, and genuinely useful: NCC 6.0 improved Logbay anonymization (ENG-748645), with stronger and more consistent masking of sensitive data in collected logs.

If you have ever hesitated before uploading a log bundle to a vendor case because you were not certain what was inside it, that is the problem being addressed. It also fixed anonymized archives corrupting AHV logs (ENG-889008), which previously made the safe option the useless one.

On the Marketplace side, Data Lens brings behavioural analytics and ransomware resilience to unstructured data across files and objects. It ships separately from the platform bundle, so it appears in none of the release notes above, but it is the piece that addresses ransomware detection rather than just recovery.

Sovereignty: Nutanix Central, on premises

One more Marketplace item deserves attention in this market specifically.

Nutanix Central On-Prem allows the unified multicloud management plane to be deployed entirely on premises, aimed at dark sites and strict regulatory boundaries.

For Luxembourg customers in financial services or the public sector, "the management plane must not leave our jurisdiction" is a common and often non-negotiable requirement. Until now that meant giving up the unified view. This closes that gap.

Like NIM and Data Lens, it is delivered through the Marketplace rather than the platform bundle, which is why it does not appear in the AOS or Prism Central release notes.

Validated designs the platform refuses to deviate from

Configuration drift is a security problem before it is an operations problem. An estate nobody can describe is an estate nobody can attest to.

Nutanix Infrastructure Manager (NIM) is a Marketplace application inside Prism Central. It builds and lifecycle manages environments that conform to Nutanix Validated Designs.

It splits an estate into a Management Domain (Nutanix Central, Prism Central, Flow, Foundation Central) and Application Domains where workloads run. It deploys against a prescriptive Bill of Materials that pins tested combinations of AOS and Prism Central.

NIM launched in February 2026 with a BOM based on PC and NCI 7.3. Rather than assume it had kept pace, we downloaded the 7.6.0 bundle and opened it.

The MD5 matches the portal listing. The BOM ships as a ConfigMap inside the Helm chart:

json
bom_v1.json  { "version": "1.0", "prism_central": "pc.7.3",   "aos": "7.3"   }
bom_v2.json  { "version": "2.0", "prism_central": "pc.7.5",   "aos": "7.5"   }
bom_v3.json  { "version": "3.0", "prism_central": "pc.7.5.1", "aos": "7.5.1" }
bom_v4.json  { "version": "4.0", "prism_central": "pc.7.6",   "aos": "7.6"   }

BOM v4.0 pins pc.7.6 with AOS 7.6. The older combinations stay available, so an estate can standardise on 7.5.1 rather than being forced onto the newest release.

The enforcement is the interesting part. Before NIM builds anything, it runs prechecks:

output
BOM_VALIDATION                     critical
HOSTING_CLUSTER_BOM_VALIDATION     critical
REGISTERED_CLUSTER_BOM_VALIDATION  critical
MANAGEMENT_PC_VERSION_VALIDATION   critical
CLUSTER_PROFILE_VALIDATION         critical

Every one is critical. NIM does not recommend a version combination. It declines to proceed without one.

Two things to watch

Prism Central may auto-lock local admin accounts after the upgrade (ENG-961947). The documented action is to contact Support. Being locked out of Prism Central immediately after a maintenance window is a bad way to start.

Legacy APIs have a deadline. Versions v0.8, v1, v2 and v3 become unsupported from the AOS and Prism Central release planned for Q2 CY2027. That is a dated compliance and migration item, and it pairs with the bash deprecation above. Both point the same way: automation moves to v4, and the timelines are now published.

Summary

In 7.6, the security posture work stopped being guidance and became platform behaviour. A STIG aligned base OS. Administrative access behind a restricted shell, with time limited vendor login available. Posture expressed as profiles. Drift caught by the health check framework. Tenancy enforced down into the network policy layer. Nine CVE fixes underneath it all.

The honest caveat is that the defaults are gentler than the feature names suggest. Enabling NuService Mode does not remove shell access, and we verified that rather than assuming it. The stricter posture exists, but it is a deliberate and irreversible step you have to choose.

For regulated customers, the practical effect is simple. Several controls that used to be consulting artifacts now arrive as product defaults.

The work moves up a level: from applying hardening, to designing the posture, proving it, and keeping it honest.

Next: the platform side of 7.6, covering capacity, scale, DR and the four conditions that will block your upgrade. Then a dedicated post mapping Security Profiles, Secure Access and NCC drift detection onto NIS2 and DORA control expectations.