The utility's SOC notices a burst of failed login attempts against a NOC administrator account, all originating from inside the account's already-permitted management subnet and consistent with an automated password-guessing attempt. Trusted hosts already restrict the account to that subnet, and the attempts are still failing on the password itself. Which account-level control most directly slows or stops this kind of repeated-guessing attempt?

A failed-login lockout threshold counts consecutive incorrect password attempts against an account and, once that count is reached, blocks further login attempts for a configured duration, which directly interrupts an automated guessing attempt regardless of where it originates or how long any one connection stays open. Shortening the idle timeout only affects how long an already-authenticated session can sit inactive before being dropped; it has no bearing on unauthenticated login attempts still failing on the password itself, so it does nothing to slow the guessing. Narrowing trusted hosts further is already moot in this scenario, since the attempts are coming from inside the subnet trusted hosts already permits, so tightening that restriction wouldn't touch traffic that already satisfies it. Raising the minimum password length is a reasonable long-term hardening step for future passwords, but it does not affect an attempt against the account's current password and does nothing to throttle or stop attempts happening right now. A caveat: set the lockout duration long enough to meaningfully disrupt automated attempts without permanently locking out a legitimate administrator who mistypes a password a few times. Verify the control by checking the event log for a lockout entry against the account after the threshold count of failed attempts, then confirming further logins are refused until the duration expires.