Adopting Multi-Admin Verification on ONTAP for High-Impact Commands

Ransomware playbooks increasingly start the same way: get one set of admin credentials, then go straight for the backups. On ONTAP, that means deleting Snapshot copies, disabling SnapMirror relationships, or turning off the very protections meant to stop the attack. A compromised or misused administrative account can alter data-protection controls quickly. Multi-Admin Verification (MAV) closes that gap by requiring a second, independent approval before a defined set of high-risk commands is allowed to run.

What MAV actually protects

MAV wraps specific ONTAP commands — the ones with real blast radius — in an approval workflow. An administrator issues the command as normal, but instead of executing immediately, ONTAP creates a pending request. One or more other authorized approvers, never the requester, must review and approve it before the operation runs. Typical rule targets include:

• volume snapshot delete and policy changes that alter retention
• snapmirror delete and relationship-breaking operations
• security login changes that touch other admin accounts
• disabling MAV itself, or removing rules from a protected rule group

MAV permits authorized operations after independent approval.

Why the base license detail matters

Unlike Autonomous Ransomware Protection or some SnapLock configurations, MAV is not a premium add-on. It has shipped in the ONTAP base license since 9.11.1, which means there's no procurement conversation, no licensing gate, and no "we'll get to it after the next renewal." If you're running an eligible on-premises ONTAP system on a supported release, MAV is available without a premium add-on. MAV is not available with Cloud Volumes ONTAP, so confirm platform support before planning the rollout. The only cost is the operational discipline to configure and test it — which is exactly why most environments that skip it aren't blocked by budget, they're blocked by not having gotten around to it.

The zero-trust case for MAV

Zero trust is usually described at the network layer — never trust, always verify, for every request regardless of source. MAV applies the same principle to administrative identity. An authenticated, authorized admin session is still treated as insufficient on its own for the small set of commands that can cause irreversible data loss. Verification doesn't stop at login; it happens again, by a second party, at the moment of the destructive action. That's the piece most privileged-access tooling misses: RBAC (Role-Based Access Control) controls who can attempt an action, MAV controls whether a single identity is ever enough to complete it.

Turning it on

A minimal initial configuration uses four commands: an approver group, two narrowly scoped rules, and the global enable with a two-person quorum:

security multi-admin-verify approval-group create -name storage-approvers -approvers admin-ana,admin-bruno,admin-carla
security multi-admin-verify rule create -operation "volume snapshot delete"
security multi-admin-verify rule create -operation "snapmirror delete"
security multi-admin-verify modify -approval-groups storage-approvers -required-approvers 2 -enabled true

From then on, a protected command doesn't execute when issued — it generates a pending request that any approver (other than the requester) can inspect and act on, and the requester re-runs the original command once quorum is reached:

security multi-admin-verify request show
security multi-admin-verify request approve -index 3
security multi-admin-verify request veto -index 3

Note that a veto is itself an auditable event — if someone is vetoing snapshot deletions at 3 a.m., you want to know why. Request and execution expiry windows are configurable on the same security multi-admin-verify modify command, which matters for the tips below.

Adoption tips that actually matter

Most failed MAV rollouts aren't security failures — they're operational ones. A few things worth getting right before flipping it on cluster-wide:

• Scope the first rule group narrowly. Start with snapshot/retention deletion and MAV self-modification commands only. Prove the workflow before extending it to broader command sets — a rule group that's too aggressive on day one just trains admins to route around it.
• Use three-plus eligible approvers with a two-person quorum. A two-approver pool with a two-person quorum means any single person on PTO blocks every request. Three or more approvers with a quorum of two keeps coverage without weakening the control.
• Set a deliberate request expiration window. Too short and legitimate maintenance windows get missed; too long and stale requests linger as an audit headache. 24 hours is a reasonable starting point for most teams.
• Wire approval requests into whatever your team already watches — EMS event forwarding to Slack, ticketing, or paging — so a pending request doesn't sit unnoticed until someone happens to check the CLI.
• Document a break-glass path before you need it. If your approver pool is unavailable during an actual incident, know in advance how to reach NetApp support or your escalation contact — don't discover the procedure while a real ransomware timer is running.
• Test the failure modes, not just the happy path. Deliberately let a request expire, veto one, and try to approve as the original requester (it should be rejected). Confirm the behavior matches what your runbook assumes.
• Review the MAV audit log on a schedule, not just after an incident. An approved-but-unusual request is often the first signal that an account has been compromised.

Where it fits in the bigger picture

MAV doesn't detect ransomware and it doesn't replace immutable Snapshot copies, SnapLock, or offline backups — it protects the control plane those defenses depend on. The layered story is: SnapLock and Snapshot locking make backups hard to destroy even with valid credentials; MAV makes sure valid credentials alone are never enough to try. Combined, they remove the single point of failure most ransomware playbooks are built to exploit — one admin account with the power to unilaterally erase the recovery path.

If MAV is not enabled, assess whether it fits the administrative and operational requirements of the environment.

Version and source note

MAV is available beginning with ONTAP 9.11.1, but supported operations and platform availability vary by release. Confirm the workflow and protected-operation list in the current MAV documentation before enabling it.