Google has rewritten the default rate-limiting schedule behind Android’s lockscreen. Its mechanics are worth understanding if you test, forensically image, or manage fleets of Android devices. The new Android lockscreen rate limiting policy replaces a schedule that tolerated 1,800 failed PIN guesses over five years with one that locks out further attempts after 20.
The old Android lockscreen rate-limiting schedule
Android 16 and earlier ship with a rate limiter that starts lenient and stays that way. A device allows 10 guesses in the first minute, 20 within six minutes, 50 within 25 minutes, and 110 within a day. The count keeps climbing to 1,800 across five years before the limiter finally stops the device. A four-digit PIN has only 10,000 possible combinations. That ceiling gives a patient attacker a meaningful shot at brute-forcing the credential outright. Common PIN patterns that cluster around birthdays, repeated digits and simple sequences make the odds even worse.
This is the same class of weakness that public tools like Android-PIN-Bruteforce have exploited for years. They drive repeated unlock attempts through ADB or the lockscreen input path on unpatched or misconfigured devices. The attack was never fast. But the old limiter never made it expensive enough to matter over a long enough timeline.
The new schedule, attempt by attempt
Google’s authentication documentation now lays out an escalating lockout curve. It is enforced by the device’s rate-limiting layer, which sits on top of Gatekeeper. On supported hardware, that layer is backed by a Weaver secure element such as Titan M or StrongBox. The first four wrong guesses cost nothing. From there, delays compound fast. Guess five costs one minute, guess six costs five minutes, guess seven costs fifteen, and guess eight costs thirty. By guess ten the wait reaches four hours, stretching into multi-day and multi-year territory from guess twelve onward. Guess twenty is the last one the device will accept. After that, PIN entry is blocked entirely, and unlocking requires a different recovery path.
The schedule is enforced by the rate limiter rather than the input UI. An attacker cannot simply script around it by resetting counters or racing the clock. That holds provided the device has the hardware-backed rate limiter Google requires for the policy to apply. Cheaper or older hardware without Weaver support may fall back to a software-only limiter instead. That is a weaker guarantee, and it is worth checking during any mobile security assessment.
Checking whether a target device is covered
Before relying on any of this during an assessment, verify it directly rather than assuming it from the Android version alone. Settings, then About phone, shows the installed OS version and security patch date, which narrows things down but does not confirm hardware support on its own. Pixel devices running Android 16 QPR2 or later have the full hardware-backed limiter. Devices from other manufacturers can report a compatible Android version while still lacking a Weaver-backed secure element, in which case the platform falls back to a software limiter with weaker guarantees. Where the distinction matters for a report’s findings, note it explicitly rather than assuming parity across devices.
Duplicate-guess detection
A second, smaller change addresses false positives in that harsher schedule. Duplicate-guess detection recognises when a user re-enters the exact same wrong PIN twice in a row. The repeat does not count against the limit, and the phone shows a distinct on-screen message instead. Without it, a much stricter lockout curve would punish ordinary typos as hard as genuine guessing attempts. That would have made the change far less usable in daily life.
What this means for testers and defenders
For anyone doing physical or lost-device security assessments, the practical takeaway is simple. Brute-forcing a modern, patched Android lockscreen through the UI or ADB is no longer a realistic path. That holds once a device runs Android 16 QPR2 or Android 17 with the hardware-backed limiter active. That does not mean the lockscreen is unbreakable. It means guessing through the front door is off the table. Chip-off extraction, bootloader exploits, and the forensic tools used by law enforcement labs still rely on entirely different techniques. None of them are touched by a rate limiter that only governs the normal unlock flow.
Enterprise administrators managing fleets through Android’s DevicePolicyManager should note something specific here. This system-level limiter sits apart from, and is stricter than, any custom maximum-failed-passwords policy an MDM might already enforce. Where an organisation’s own policy allows more attempts than the new default permits, the platform’s floor now takes precedence on devices that receive the update. That is worth checking against existing device-compliance baselines rather than assuming the old numbers still apply.
The bigger caveat for any assessment is fragmentation. Pixel phones will pick up Android 17 quickly. Many other manufacturers take six months to a year, and some budget devices never receive the update at all. Any fleet inventory or pentest scope that assumes the new limiter is universally in place should verify this first. Check the installed Android version and security patch level rather than assuming the protection is already there.
