Backup software is deliberately powerful: it reads protected data and can restore it elsewhere. Its service identity therefore deserves the same ownership, vaulting and monitoring as other privileged infrastructure accounts.

Use the installed version as authority

Record Backup Exec version, update level, Windows/domain topology, protected workloads and current service/logon accounts. Check the current Veritas guide and compatibility list for that exact release.

Backup Exec 25 documents specific group memberships and user rights for its service account and destination access. Do not remove rights merely because a generic hardening checklist says “least privilege.” Least privilege means the minimum vendor-supported scope for the deployed functions, not an invented configuration that silently breaks restore.

Separate the account roles

Distinguish:

  • the Windows identity running Backup Exec services;
  • the Backup Exec System Logon Account stored in the product;
  • resource-specific logon accounts for servers, shares, applications or devices; and
  • human accounts authorised to administer Backup Exec.

Veritas documents that the service and system logon accounts begin aligned, and that changing the service username requires reconciling the system logon account. A stored Backup Exec logon account is not itself a Windows account; it is a credential record used by jobs and browsing.

Do not run services under a named technician or departing employee. Use a dedicated owned service identity with a vault record, rotation process, accountable custodians and no ordinary email/web use.

Inventory every dependency before rotation

List services, System Logon Account, job/resource credentials, scheduled tasks, SQL/database dependencies, remote agents, NAS/appliances, cloud connectors and restore workflows. Record which jobs inherit a default account and which override it.

Take a current Backup Exec configuration/catalogue/database backup through the supported method and verify the break-glass administrative path. Preserve the last successful backup and restore evidence.

Create the supported identity

Create the account in the correct security boundary and apply only the current Veritas-required groups/rights plus resource access needed for selected workloads. Scope access to backup servers/destinations where the product permits it. Deny or avoid interactive use only when compatible with Veritas requirements and operational recovery.

Use a long managed password or approved managed service mechanism only if Backup Exec explicitly supports it for this role/version. Store recovery custody outside the server.

Monitor logon, privilege use, group changes and password events. A supported high-privilege requirement needs compensating control, not denial.

Change credentials through Backup Exec

Use the Backup Exec Services Manager/Utility procedure for the installed version so services and stored product state remain consistent. Verify the existing credential as required, apply the new identity and let the product grant documented service rights where appropriate.

Reconcile the System Logon Account and replace account references in affected jobs/resources. Do not edit Windows Services alone: the services may start while Backup Exec continues presenting stale credentials to protected resources.

Avoid changing service identity, repository credentials and many job accounts simultaneously. One bounded change leaves meaningful failure evidence.

Verify backup and restore

Confirm all Backup Exec services run under the intended identity and no old credential remains referenced. Test account access against representative sources, but treat that only as preflight.

Then run representative file, system-state/application-aware and destination jobs. Confirm selection, byte count, VSS/application result, target write, catalogue and retention.

Restore representative data to an alternate controlled location and validate content plus permissions. Test one workload that uses a resource-specific account and one using the system/default account. Confirm unauthorised Backup Exec users cannot use restricted credentials or restore sensitive data elsewhere.

Operate the account lifecycle

Document password rotation, expiry/managed-secret behaviour, emergency recovery, monitoring and owner succession. Test rotation before the current credential expires. Remove the old account only after all jobs, agents and restore paths pass through a complete schedule.

The service-account change is complete when the product and Windows agree on the identity, every credential reference is reconciled, backups and restores succeed, unsupported access is denied and no person’s account remains a hidden infrastructure dependency.