The server failed. The audit log said nothing. No one knew who had the keys, or why they were used.
That is what happens when Separation of Duties exists only on paper. In manpages, the principle is clear: no single person should have the power to both execute and approve. It protects systems from mistakes, fraud, and silent privilege creep. But for Separation of Duties to work in real environments, it must be precise, enforced, and visible.
In technical terms, manpages define commands, tools, and permissions. They specify who can run sudo, who can write to sensitive files, and who can trigger deployments. Misalignment between these definitions and actual team practices is a time bomb. Many teams read the manpage. Few map it to real operational boundaries.
True Separation of Duties starts with splitting operational roles at the smallest functional level: a person who writes code does not deploy it directly. A person who approves database changes does not apply them. A person who can reset credentials is not the same person who can create them. This is not just a compliance checkbox—it’s a resilience pattern.