The root cause wasn’t zero-day malware or a nation-state attack. It was a vendor account with a password that hadn’t been changed in over a year.
Password rotation policies are one of the simplest controls in vendor risk management, yet they fail too often. Vendors hold keys to sensitive systems. If those keys stay static, their security degrades over time. Credentials leak in forums. Phished logins get sold. Stale passwords become weak points no matter how complex they are.
A strong password rotation policy requires clear rules for how often passwords change, how they are generated, and how they are stored. Ninety days is common, but high-risk integrations may need shorter cycles. Rotation must be enforced, with automated checks and alerts when a vendor fails to comply. Storing rotation data in a central system allows verification and audit.
Vendor risk management isn’t only about contracts and questionnaires. It means verifying that identity controls work in practice. Password rotation should be part of mandatory security clauses in vendor agreements. Vendors must prove rotation through logs or API reports. Policies should extend to API keys and service accounts, not just human logins.