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
adminuser 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:
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:
============================
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:
****** 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)
------ 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
nutanixuser 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:
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:
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.


