A retention setting on the appliance changed at some point last week. The customer wants a name and a timestamp, and the only constant in the environment is that the operations desk shares one administrator login 'for convenience'. What makes future change history actually usable?

Change history is only as good as the identity model underneath it. The appliance logs commands and login events against the authenticated user, so if the operations desk shares one administrator credential, every change - good, bad, accidental - lands in a single undifferentiated trail and 'who' is permanently unanswerable however fine the logging. The fix is structural: individual named or directory-mapped accounts so each command carries a person, plus forwarding the log stream to a collector that retains it independently, because an audit trail that exists only on the device it describes is fragile. Monthly configuration snapshots answer what changed and only bracket when; they can never supply the who, which is the question actually asked. Backup-application command logs miss the changes that matter most - anything a human made directly on the appliance's own management interfaces, which is precisely where a retention setting gets altered. Hourly configuration diffs repeat the same fallacy: configuration state records the delta, not the identity, and tightening the interval sharpens the when while the who stays blank. Exam caveat: per-person accountability usually needs a documented exception path for vendor support sessions - see the support-access practice in this same objective. Operational check: with named logins in force, make one test change as a test user and trace it, name and timestamp intact, in the forwarded logs.