Security work has a reputation problem. Everyone agrees it matters. Almost nobody enjoys the part where you sit down with a hardening guide, a terminal window, and dozens of individual settings that each need to be right, on every node, in every cluster, forever.
Nutanix Cloud Infrastructure 7.6 takes a swing at that problem. Alongside AHV 11.2 and Prism Central 7.6, this release introduces Nutanix Security Profiles: three pre-built hardening postures you select once in Prism Central, and the platform applies across both the AOS and AHV layers.
The problem with knobs: Fine-grained control sounds good until you have to exercise it.
The old model asked administrators to reason about individual toggles, kernel mitigations, password policy, file integrity monitoring, core dump behavior, largely through CLI commands, and to keep them consistent across a fleet. That model had two failure modes, and both were common:
- Set something wrong and pay for it in performance. Several hardening options carry real overhead. Enabling them without understanding the trade-off can quietly degrade a cluster.
- Miss something and never know. You believe the cluster is hardened. It’s hardened almost everywhere. Nobody finds the gap until an audit or an incident does.
Neither failure announces itself. That’s what makes fragmented configuration expensive — not the time spent setting it, but the time spent verifying it stayed set.
Three profiles instead of dozens of toggles: Security Profiles consolidate a large portion of the Nutanix hardening guide into three named postures:
- Standard: the recommended baseline profile. Balances meaningful hardening against performance, with minimal overhead. Weekly SCMA scheduling, an 8-character minimum password length, five allowed login attempts.
- Elevated: turns on CPU vulnerability mitigations and tightens identity controls. High-strength passwords, a 16-character minimum, three login attempts, and kernel and processor mitigations enabled. On AHV, this adds SRSO, Retbleed, and iTLB Multihit mitigations. Expect a higher performance cost — that’s the deal you’re making.
- Strict: aimed at highly regulated environments. Adds AIDE file integrity monitoring, login banners, slub debug, page/memory poisoning, and (on AHV) fapolicy. Userspace and kernel core dumps are turned off, and account-lockout behavior is tightened.
Both the AOS and AHV layers have their own setting matrices, and they don’t line up perfectly; AHV picks up items like auto-unlock and fapolicy, AOS carries the SCMA schedule. Worth reviewing both tables in Nutanix’s official technical overview of NCI 7.6 Security Profiles before you commit to a tier.
What profiles don’t cover: This is the honest caveat, and Nutanix leads with it rather than burying it: profiles handle settings that reduce to an on/off decision. Anything requiring external input, syslog server destinations, AOS Network Segmentation, or LDAP configuration, stays manual. The Nutanix Security Guide on the Support Portal remains the reference for that remainder.
The pitch isn’t “hardening is solved.” It’s “hardening is now mostly a menu selection, and you close out the rest.”
What happens when you click Apply: The workflow underneath is more interesting than the UI suggests.
- Validation. The request routes to one cluster node designated as orchestrator, which runs pre-checks against cluster health before anything changes.
- Cluster-wide sync. The intent is written to Zookeeper. A watcher fires on every node and pushes configuration down through Salt states and the AHV Gateway.
- Rolling reboot. When a selected profile changes kernel-level security settings, the affected hosts require a reboot. The orchestrator handles this through a ClusterManager RPC, evacuating workloads, rebooting one node at a time, and validating each before moving on. The workflow is designed to help preserve application availability.
- Completion. The orchestrator watches for all reboots to finish, then marks the task complete.
The reboot step is the one to plan around. Applying kernel-level settings may trigger an orchestrated rolling reboot across the cluster, so schedule the change during an appropriate maintenance window.
Drift doesn’t get to happen quietly: Applying a configuration is easy. Keeping it applied is the actual problem, and 7.6 addresses it in two ways.
First, once a profile is active, the legacy per-setting mechanisms are blocked from modifying those values. You can’t quietly reach around the profile.
Second, a security cron job runs every two hours to detect and auto-remediate drift. Where a fix can be applied in place, the system self-heals. Where correcting the drift would require a host reboot or kernel-level changes, the cluster typically raises an NCC alert instead of rebooting a host out from under you. An administrator reviews and decides.
That last design choice is the right one. Auto-remediation that reboots production hosts on its own schedule would be a cure worse than the disease.
Deployment Notes:
- Version Requirements: AOS 7.6, Prism Central 7.6, and AHV 11.2. Running a different hypervisor? Profiles still apply, but only to the AOS layer.
- Post-upgrade behavior: After upgrading, your profile shows as not set. This is deliberate; auto-applying a posture could stomp on hardening you’d already done by hand. Review your current state, then explicitly choose a tier.
That second point deserves emphasis, because “not set” is easy to mistake for “done.” Upgrading to 7.6 gets you the capability. Selecting a profile gets you the benefit. Add it to the post-upgrade checklist.
Before you apply a profile: Treat the profile selection as a planned infrastructure change rather than a simple UI preference. Nutanix rates the Elevated and Strict profiles as having a high performance impact, while Standard is rated minimal.
- Review the AOS and AHV setting matrices and identify any existing custom hardening.
- Confirm version and platform compatibility in the current release notes.
- Test the selected profile against representative workloads where possible.
- Plan for any rolling reboots required by kernel-level changes.
- Validate the resulting posture and address settings that remain outside the profile.
Summary: The value here isn’t that Security Profiles do something previously impossible. Everything in these tables could be set before. The value is that they turn a sprawling, error-prone, per-node checklist into a decision you make once, and the platform defends on your behalf.
That’s a meaningful change in where administrator attention goes. Less time proving the cluster is configured the way you think it is; more time on the things a profile can’t decide for you.
If you’re already a customer, review compatibility, test the profile that fits your requirements, and plan an appropriate maintenance window before applying it. If you’re evaluating Nutanix, ask your account team to demonstrate how Security Profiles manage hardening and configuration drift at scale.
What Do You Think? Will you use Security Profiels?? Which new feature has had the biggest impact in your environment?
Is this release something you’re excited about? Did we miss any features you’re curious about? Feel free to share your thoughts in the comments below; love to hear from you!
