In go-live week of a Data Domain deployment, three contractors and two staff engineers are all logging in with the built-in administrator account. What should change about system access?

Named identities are what make authorization, auditing, and lifecycle management real: each administrator authenticates as themselves, commands in the audit record carry a person, and a role change or departure touches exactly one account. DDOS supports named users with assigned roles through the same authentication framework the built-in account uses. The built-in administrator still matters - it is the fallback when an external identity path fails - but it should be locked down, its credentials escrowed and its use treated as an event worth investigating. A shared vault around a shared credential governs the secret, not the identity: every action still arrives wearing the same name, attribution stays impossible, and a departed contractor's knowledge of the credential forces a team-wide rekey. A second shared account for contractors simply replicates the problem at smaller scale, and externals are exactly the population whose departures need clean offboarding. Deleting the built-in account outright trades one risk for a sharper one: if directory authentication misbehaves, that account can be the only way back in, so the correct move is restriction and escrow, not deletion. Exam caveat: pair named accounts with per-user authentication and idle-session policy to complete the access-control story. Operational check: five named accounts exist and are in daily use, the shared pattern has stopped, and the built-in credentials are held under documented emergency control.