Your Passwordless Program Bought a Control, Not a Process
The costly assumption is remediation: issued tokens outlive the credential reset your incident playbook is built on, and two of the four exposure windows sit on a vendor's clock.
One pattern, four windows
The exposure window is the unit of attacker economics now, and today's reporting prices it four ways. A Chromium fix landing upstream before Chrome ships it downstream is a scheduled, reusable window. ConnectWise's ScreenConnect authentication bypass left privileged remote-access tooling exposed across downstream customers for five days, entirely on the vendor's clock. Google's Early Access channel puts over-permissioned utilities onto employee Android devices with reduced vetting. A passwordless rollout creates months in which users have no mental model of what a legitimate prompt looks like, and attackers are pricing that confusion accurately.
| Vector | What actually changed | Window length | Who controls the clock |
|---|---|---|---|
| Enrollment abuse via helpdesk pretext | Attack moved from credential theft to token issuance | Duration of your entire rollout | You |
| Upstream-to-downstream browser patch gap | Public fix precedes shipped fix, predictably | Every Chromium release cycle | Vendor |
| Remote-access auth bypass | Privileged tooling exposed pre-patch | Five days | Vendor |
| Pre-release mobile app channel | Reduced vetting reaches managed and BYOD devices | Persistent until policy closes it | You |
The remediation assumption that fails
Device-code compromise issues refresh tokens that survive password resets. Rotation invalidates the password and leaves the refresh token live, so a playbook centered on credential rotation closes the incident on paper only. A tabletop exercise surfaces this in an afternoon. Eviction time is the metric to instrument: detection to dead token, target under an hour.
Where this stops being a security problem and becomes a procurement one
Two of the four windows close with policy. Two are hostage to a supplier's release cadence, and patch latency belongs in contracts for that reason, not only in engineering retrospectives. Few suppliers will sign a measured disclosure-to-patch number, and the ones that will are the ones worth the renewal. Written into top vendor agreements and into third-party risk scoring at renewal, that number converts an engineering complaint into an enforceable term. Suppliers will begin quoting their own patch latency in sales material, and the buying side should have its own figure ready when they do.
What the board pack should stop reporting
Both security desks reached the same structural conclusion, and one states it plainly: confidence and preparedness are not necessarily true measures of security. That is a candid concession from a genre that sells readiness, and it marks the vendor-sponsored readiness report as a weak buying input. The same skepticism applies to internal reporting. Control coverage, attack-path reduction, and detection and containment latency are measurable. Self-reported readiness scores are what most board packs carry instead.
Sourcing caveat: the reporting is headline-level, with no CVE identifiers, affected versions or indicators of compromise. The strategic pattern holds across both sources; the technical particulars need validation against vendor advisories before anyone briefs detail.
The attacker enrolls a passkey during the rollout window. Resetting the password leaves the enrollment intact.
What to do
Gate or disable OAuth device-code flow tenant-wide, then run a token-revocation tabletop with a one-hour eviction target.
Add measured disclosure-to-patch commitments to your top vendor contracts and third-party risk scoring at the next renewal cycle.
Replace self-reported readiness metrics in board security reporting with control coverage, attack-path reduction and containment latency before the next board cycle.