The application team wants a security-related setting changed on the appliance. The engineer who performs all day-to-day administration 'already knows the password' and offers to make the change himself inside this week's window. What does that sentence reveal that should be fixed in the configuration, not in his attitude?

The sentence 'he knows the password, he can just do it' describes a separation-of-duties hole, and DD OS closes that hole in configuration: role definitions can place security-sensitive administration - authentication settings and comparable areas - in a security-focused role held by different people from the day-to-day administrator, so no single routine operator can unilaterally alter the security posture. The design intent is that sensitive change requires, by structure rather than promise, a second pair of hands. A change ticket with manager sign-off is a fine procedural layer, but it leaves the technical capability wholly in one person's hands - the process records the decision while the configuration still lets the same person execute anything. One person splitting himself across two of his own accounts adds identities, not duties: the same human owns both sides of the pretend separation, and the next audit gets a murkier story, not a cleaner one. Two engineers sharing one admin password manufactures the shared-identity failure this objective exists to prevent - dual control through a single credential destroys the per-person evidence that would show what each of them actually did. Exam caveat: separation cuts both ways - the security role should not hold routine change rights either; the split is mutual. Operational check: the routine admin attempts the sensitive change and is denied; the security-role holder performs it, and the two trails remain distinct.