A backup application's setup wizard is asking for Data Domain credentials for its optimized Boost path, and the engineer reaches for the sysadmin login used during commissioning because it is already open in another browser tab. What credentials should the application actually be given?

Application-facing identities should be purpose-built on the appliance: a user whose role grants only the operations its integration performs, bound to the specific MTrees it writes, registered in the appliance's storage-unit configuration and in the application's target settings. Least privilege then contains the blast radius of a compromised media server or a leaked config file, password rotation of the application secret stops being an outage for administrators, and audit records attribute activity to the application rather than to a person whose name is on the admin login. The administrative-requirement claim is false, since Boost operation needs a storage-unit-registered user with mtree-scoped access, not device-level administration from the connecting side. A permitted-host list restricts where sessions may originate but does not replace authentication on the optimized path, so credentials are unavoidable, and inventing a credential-less mode misstates the mechanism. A shared vault account destroys attribution and turns every rotation into a coordinated site-wide change, which is precisely the pattern least-privilege design removes. Exam caveat: keep the as-built clear on which application owns which account so decommissioning is safe. Operational check: after switching to the dedicated user, run a successful backup and confirm the account cannot administer the system or touch paths outside its scope.