The sole administrator plans to rotate the encryption keys alone at midnight 'to avoid disruption'. An auditor flags the plan. Which platform security capability is being missed, and what does configuring it correctly involve?
Select an answer to reveal the explanation.
Short Explanation
Two-person integrity exists for exactly this moment - midnight, alone, keys in hand. If dual-admin isn't configured ahead of time with real named people and escrow, the control simply doesn't exist when the auditor asks. You can't bolt on the second person at the moment you need them.
Full Explanation
Dual-administration mode gates defined sensitive tasks behind two distinct administrator authentications, so no single person, however senior, can rotate or destroy key material alone. The configuration is the substance: enable the mode, choose the gated operations, name the holders, and escrow their credentials so a midnight necessity has a real second party, not an excuse. A solo key rotation at midnight is precisely the scenario the feature exists to prevent. A dedicated key-admin role is separation of duties - valuable, but one human with a role is still one human; the auditor objected that a single person can act, and roles alone don't stop that. An audit log is forensic: it proves the rotation happened, after the fact, and recording an unauthorized solo operation never retroactively authorizes it - prevention versus evidence is the line compliance draws. Time-window enforcement restricts when a solo admin may act, not how many people must - it leaves the single-point-of-control problem completely intact inside the window. Exam caveat: dual-admin typically covers crypto-erase and key-management paths, but the gated task list varies by version - enumerate it before writing the runbook. Operational check: in a planned window, walk a rotation request through the dual-approval flow end to end and verify both administrators' actions appear in the audit trail before the change executes.