NetApp ONTAP Security Hardening Guide: Admin Access, Snapshot Locking and Multi-Admin Verification

A storage administrator who can delete volumes and snapshots can undo every recovery plan the organisation has, and ransomware operators know it. NetApp ONTAP holds file shares, LUNs, virtual machine datastores and the snapshots many teams treat as their first line of recovery, so the cluster management plane is a high-value target. This guide works through ONTAP hardening from the identity side: administrator accounts and roles, multifactor authentication, API credentials, multi-admin verification (MAV), tamperproof snapshot locking, Autonomous Ransomware Protection (ARP), protocol settings and log forwarding. It is written for storage, infrastructure and security engineers, and it follows NetApp's own hardening guidance (TR-4569, now published on docs.netapp.com) and the ONTAP product documentation. Version numbers are given because many controls only exist from a particular ONTAP release.

Key takeaways

• Treat ONTAP admin accounts as privileged identities: lock the built-in admin and diag accounts you do not use, give named people the narrowest predefined or custom role, and require SSH MFA.
• Multi-admin verification is the control that stops a single stolen admin login from deleting volumes, snapshots or changing security settings, available from ONTAP 9.11.1.
• Locked snapshots survive a rogue administrator: tamperproof snapshot locking (9.12.1 and later) uses the SnapLock compliance clock so snapshots cannot be deleted until their retention expires.
• Automation needs its own identities: use certificate-based or OAuth 2.0 authentication for REST API callers, never a shared admin password in a script.
• Logs only help if they leave the cluster: forward audit and event data with cluster log-forwarding over tcp-encrypted to a SIEM the storage team cannot alter.

How identity and access work in ONTAP

ONTAP separates administration into the cluster (the admin SVM) and data storage virtual machines (SVMs). Each login is a combination of a user or group name, an application (how the user connects) and an authentication method, mapped to a role. The same person can therefore have different methods for SSH, HTTP (System Manager and REST) and ONTAPI, which is useful and also a source of forgotten access paths. security login show lists every combination.

For remote accounts, Active Directory users can use an SSH public key as the primary or secondary method from 9.13.1, and LDAP or NIS users can use SSH MFA from 9.4. SAML is available for the admin SVM and covers System Manager, ONTAP APIs and the Service Processor infrastructure. When SAML is in use, the System Manager inactivity timeout is controlled by the identity provider rather than ONTAP. See the Privileged Access Management Guide for how these accounts should fit the wider privileged access programme.

Admin roles and privileged access

Built-in accounts

ONTAP ships with two default administrative accounts, admin and diag. Built-in accounts cannot be removed or renamed: NetApp notes that a removed built-in account is recreated on reboot and recommends locking any built-in account you do not need with security login lock. The diag account is the only account that can enter the systemshell through the diag-privilege systemshell command, and NetApp reserves it for troubleshooting under technical support guidance. Set a strong diag password with security login password, change it regularly and keep it in the PAM vault.

Predefined roles

Password and lockout policy

Password rules are set per role with security login role config modify. The defaults are weak for an administrative plane: minimum password length 8, max-failed-login-attempts 0 (no lockout), password expiry unlimited, and account inactivity limit unlimited. NetApp notes that stronger complexity and lockout rules from 9.14.1 apply only to new installs, so upgraded clusters keep the old defaults until you change them. Set a longer minimum length, a lockout threshold, account-inactive-limit to disable dormant accounts, and require-initial-passwd-update for new accounts. ONTAP 9 hashes new or changed passwords with SHA-512; accounts carried over with MD5 hashes can be found with security login show -fields hash-function and forced to change with security login expire-password -hash-function md5.

Sessions and the Service Processor

• CLI timeout: the default is 30 minutes; check with system timeout show and set with system timeout modify. System Manager has its own inactivity timeout (2 to 180 minutes).
• Login banner: set with security login banner modify at cluster level; data SVMs inherit it unless they define their own.
• Service Processor or BMC: only supports password authentication, and SVM accounts cannot reach it. Restrict source addresses with system service-processor ssh add-allowed-addresses.
• Break-glass: keep one locked local admin path for identity provider outages, with its credential sealed in the vault. See the Break-Glass Account Guide.

Integrations, API tokens and service accounts

Storage clusters accumulate machine callers: backup software, hypervisor plug-ins, monitoring, Ansible or Terraform pipelines, Kubernetes CSI drivers and NetApp's own management tools. Each of these is a non-human identity with a credential that can often delete data. NetApp's hardening guidance states that certificate-based authentication must be used for REST API or Manageability SDK access instead of user ID and password, with OAuth 2.0 token-based authentication (from ONTAP 9.14.1) as the alternative, where tokens replace passwords for the account.

The certificate common name maps to the ONTAP user ID, so the private key is the credential: store it in a secrets manager, set an expiry and rotate it. From 9.13.1 ONTAP checks SSH public keys and certificates for expiry and revocation, and OCSP checking (off by default) can be enabled per application with security config ocsp enable. The certificate example in NetApp's documentation uses the admin role for illustration only; give automation a custom role. See the Service Account Security Guide and the SSH Key Management Guide.

Multi-admin verification and snapshot locking

These two features address the scenario that matters most for ransomware: an attacker holding valid administrator credentials (ATT&CK T1078 Valid Accounts) who tries to remove recovery options (T1490 Inhibit System Recovery) before encrypting or destroying data (T1486, T1485). See the T1490 Inhibit System Recovery Defensive Guide.

Multi-admin verification (MAV)

• How it works: a protected operation generates a request, the required number of MAV administrators approve it within the approval expiry, and the requester then runs it within the execution expiry. Requesters cannot approve their own requests.
• Set-up: create an approval group (security multi-admin-verify approval-group create), enable MAV (security multi-admin-verify modify) and add rules (security multi-admin-verify rule create -operation "volume snapshot delete"). After initial set-up only MAV administrators can change these elements, and the MAV commands themselves are protected by system-defined rules.
• What to protect: at minimum volume deletion, snapshot deletion, snapshot policy changes, security login changes and ARP configuration. NetApp recommends MAV for ARP changes from 9.13.1.
• Group sizing: if MAV administrators must also run operations, the group needs one more member than the required number of approvals. Clusters with only one administrator should not enable MAV.
• Automation: MAV is not designed for heavily automated workflows. Use -query constraints, for example excluding snapshots named hourly*, so scheduled jobs run without approval while manual deletion of other snapshots still needs it. Anything excluded by a query is unprotected.
• Limits: RBAC is evaluated before MAV, so MAV complements roles rather than replacing them. MAV is not available on Cloud Volumes ONTAP, and disabling it without approval requires NetApp Support.

Tamperproof snapshot locking

• Requirements: ONTAP 9.12.1 for the CLI (9.13.1 for System Manager), a SnapLock licence (included in ONTAP One) and an initialised compliance clock. It does not require SnapLock Compliance or Enterprise volumes.
• Enable: volume modify -snapshot-locking-enabled true, then add a retention period to the snapshot policy (volume snapshot policy create ... -retention-period1) or set -snaplock-expiry-time on individual snapshots. SnapMirror policy rules can carry a retention period for the destination.
• Consequences to plan for: locked snapshots cannot be deleted, the volume cannot be deleted, and the cluster cannot be reverted to an earlier ONTAP release until they expire. Retention overrides the keep count, so capacity planning must account for it.
• Not supported: consistency groups, FabricPool, SMtape and SnapMirror active sync.

Lock snapshots on the SnapMirror or SnapVault destination as well as the source, and keep the destination cluster under separate administrator identities. The Backup Identity Isolation Guide covers why separate credentials matter.

Logging and detection

• Forward logs off the cluster: cluster log-forwarding create -destination <host> -port <port> -protocol tcp-encrypted -verify-server true. NetApp recommends forcing tcp-encrypted; udp-unencrypted and tcp-unencrypted should not cross untrusted networks.
• Event notification: use event notification create with filters to send EMS events to syslog, SNMP trap hosts or email, so ARP alerts and MAV requests reach the SOC as well as the storage team.
• NAS auditing: vserver audit create records share changes, audit policy changes, local user and group changes, privilege changes and file access events; it must be enabled to generate SMB audit events.
• FPolicy: vserver fpolicy policy create with the native engine can block file extensions and feed file activity to external monitoring.
• Autonomous Ransomware Protection: ARP (9.10.1 to 9.15.1) watches entropy, file extensions and operation surges after a 30-day learning period on NAS FlexVol volumes. ARP/AI (9.16.1 for NAS, 9.17.1 for SAN) needs no learning period for NAS, though SAN volumes need a 2 to 4 week evaluation period. ARP/AI also takes snapshots every 4 hours from 9.17.1 with a default 12-hour retention.
• Digital Advisor checks: NetApp's hardening guidance lists checks such as AutoSupport over an insecure protocol, missing cluster login banner, insecure SSH ciphers, volumes without snapshot policies, snapshot auto-delete enabled and NAS SVMs without native FPolicy.

Useful metrics: percentage of production volumes with locked snapshots; percentage of protected operations covered by MAV rules; number of human accounts with admin; percentage of SSH administrators with a second authentication method; age of the oldest API certificate; and days since log forwarding last failed. See the Log Management and Retention Guide.

Hardening baseline

Rollout order

1. Inventory: export security login show for the cluster and every SVM, and map each entry to a person or system owner.
2. Identity first: lock unused built-in accounts, move people to directory or SAML accounts with SSH MFA, replace shared automation passwords with certificates or OAuth 2.0.
3. Logging: enable encrypted log forwarding and event notifications before you change protection settings, so changes are recorded.
4. Snapshot locking in a pilot: start with a short retention on non-critical volumes, check capacity and the revert restriction, then extend.
5. MAV: create the approval group, add rules with -query exclusions for automated jobs, and test approval and veto with the storage and security teams before enabling broadly.
6. Crypto and protocol settings: test TLS, SSH and FIPS changes on a non-production cluster with console access, because clients that cannot negotiate will lose management access.
7. Rollback: most settings revert with the same modify commands. Locked snapshots and MAV are deliberately hard to undo, so document that before enabling them.

Common misconfigurations

• Everyone uses the admin account: there is no individual accountability, and one phished password gives full control. Named accounts and roles fix both.
• Snapshots are the only copy and are deletable: without locking or MAV, an attacker with admin rights removes them first. Snapshot auto-delete enabled on a volume has the same effect under capacity pressure.
• MAV rules with broad queries: excluding every snapshot prefix to keep automation running leaves nothing protected.
• Backup software with cluster admin: integrations often ask for full rights. Use vsadmin-backup or a custom role, and isolate the backup platform's own admin plane.
• Upgraded clusters keep old defaults: TLSv1.1, MD5 password hashes and weak password policy can survive upgrades. Re-check after each upgrade.
• Logs stay on the array: syslog over UDP or no forwarding at all means an attacker with admin rights can act unseen.

Framework mapping

Practitioner checklist

• Export and review security login show for the cluster and all SVMs; lock unused built-in accounts.
• Require a second SSH authentication method (TOTP, public key or FIDO2) for every human administrator.
• Give each automation its own certificate or OAuth 2.0 identity with a custom role; remove shared passwords.
• Strengthen security login role config: length, lockout, inactivity limit, initial password change; expire MD5 hashes.
• Enable MAV with an approval group of at least two people and rules for volume and snapshot deletion, login and ARP changes.
• Enable tamperproof snapshot locking on critical volumes and their SnapMirror destinations.
• Enable ARP or ARP/AI and route its events to the SOC.
• Forward logs with tcp-encrypted and -verify-server true; alert when forwarding stops.
• Restrict management LIFs and the Service Processor to admin networks; keep TLS at 1.2 or above.
• Re-run this checklist after every ONTAP upgrade.

Standards and references

• NetApp: ONTAP security hardening guide (TR-4569)
• NetApp: Multi-admin verification overview
• NetApp: Lock snapshots to protect against ransomware attacks
• NetApp: Autonomous Ransomware Protection
• NetApp: Administrator authentication and RBAC
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Inhibit System Recovery

Related NHI Mgmt Group resources: Backup Security and Immutable Backup Guide · Ransomware Response and Recovery Guide · Privileged Access Workstations Guide · SMB Signing Guide · TLS Server Configuration Baseline Guide