a login with no off switch
The Permission You Cannot Take Back
The FBI is warning Microsoft 365 users about a device-code phish that survives a password reset. Passwordless login moved the lock to a place you can no longer reach.
A device-code login does one thing: it lets a machine with no keyboard borrow your hands. A smart television, a printer, a console with no good way to type a long password shows you a short code and a web address. You go to that address on your phone, enter the code, sign in, clear multifactor, and the keyboardless device is now logged in. You authorized it from a device you trust. That is the whole design, and it works.
The FBI is warning Microsoft 365 users about a scam called Kali365 that uses exactly this flow against them. The attacker is the keyboardless device. He starts the device-code grant, gets the short code, and sends it to you wrapped in a message that looks like routine account business. You go to the real Microsoft page, because it is the real Microsoft page, and you enter the code, and you clear multifactor, because all of that is genuinely you. The login completes. The session token lands in the attacker's waiting browser.
The credential that mattered was never a secret you knew. It was a permission you had already given.What the token holds
Every tool is a transfer of custody, and the question is always who ends up holding the record it makes of you. Here the record is the token, and the token is custody of the session: your mail, your files, your contacts, the standing right to act as you until the grant expires. Multifactor did not fail. It worked, on the wrong machine, for the wrong device, with your full and unhesitating consent.
This is the part the word "passwordless" was meant to skip over. The password was a thing you held, and a thing you hold is a thing you can change. Resetting it locked people out, cleanly, in one move. A device-code token is not a thing you hold. It is a thing you signed. Changing your password does not call it back. The grant sits in the attacker's session, valid, until something else expires or revokes it, and most people do not know where that something is, or that it exists.
A token is consent with a life of its own. Signed in one trusting second, filed somewhere you were never shown, and revocable only from there.
So the recovery is no longer a single act. You change the password and feel safe, and the open session keeps reading your mail in another country. The real remedy is to revoke active sessions and refresh tokens, sign out everywhere, and audit what consented. Almost no one does this, because nothing in the experience of being phished tells you that the password was the smaller half of the lock.
Treat the login screen as what it is now: an act of issuing, not an act of passing through. Every sign-in mints a permission with its own life, its own duration, its own custody, sitting somewhere after you walk away. Read the code before you type it. Ask what is actually asking.
Change the password. The grant stays where you left it.
The same record an agent receives. No scraping, no guessing — the dossier chrome humans read as dread is the metadata machines read as structure. One source of truth.
--- id: PRG-0045 title: The Permission You Cannot Take Back kicker: a login with no off switch captured: 2026-06-28T14:05:00Z status: open author: Aldous Renn summary: The FBI is warning Microsoft 365 users about a device-code phish that survives a password reset. Passwordless login moved the lock to a place you can no longer reach. tags: [custody, permission, credentials, capture] source: https://www.foxnews.com/tech/fbi-warns-microsoft-users-passwordless-scam sealAt: 2026-07-28T14:05:00Z --- A device-code login does one thing: it lets a machine with no keyboard borrow your hands. A smart television, a printer, a console with no good way to type a long password shows you a short code and a web address. You go to that address on your phone, enter the code, sign in, clear multifactor, and the keyboardless device is now logged in. You authorized it from a device you trust. That is the whole design, and it works. The FBI is warning Microsoft 365 users about a scam called Kali365 that uses exactly this flow against them. The attacker is the keyboardless device. He starts the device-code grant, gets the short code, and sends it to you wrapped in a message that looks like routine account business. You go to the real Microsoft page, because it is the real Microsoft page, and you enter the code, and you clear multifactor, because all of that is genuinely you. The login completes. The session token lands in the attacker's waiting browser. <Highlight>The credential that mattered was never a secret you knew. It was a permission you had already given.</Highlight> ## What the token holds Every tool is a transfer of custody, and the question is always who ends up holding the record it makes of you. Here the record is the token, and the token is custody of the session: your mail, your files, your contacts, the standing right to act as you until the grant expires. Multifactor did not fail. It worked, on the wrong machine, for the wrong device, with your full and unhesitating consent. This is the part the word "passwordless" was meant to skip over. The password was a thing you held, and a thing you hold is a thing you can change. Resetting it locked people out, cleanly, in one move. A device-code token is not a thing you hold. It is a thing you signed. Changing your password does not call it back. The grant sits in the attacker's session, valid, until something else expires or revokes it, and most people do not know where that something is, or that it exists. > A token is consent with a life of its own. Signed in one trusting second, filed somewhere you were never shown, and revocable only from there. So the recovery is no longer a single act. You change the password and feel safe, and the open session keeps reading your mail in another country. The real remedy is to revoke active sessions and refresh tokens, sign out everywhere, and audit what consented. Almost no one does this, because nothing in the experience of being phished tells you that the password was the smaller half of the lock. <Marginalia label="On the convenience">The device-code flow is not a flaw. It is a genuine convenience, built honestly, for a real problem. It became a weapon the moment the thing it grants outlived the moment of granting. Most surveillance arrives this way: as a feature you asked for, holding a permission you forgot you signed.</Marginalia> Treat the login screen as what it is now: an act of issuing, not an act of passing through. Every sign-in mints a permission with its own life, its own duration, its own custody, sitting somewhere after you walk away. Read the code before you type it. Ask what is actually asking. Change the password. The grant stays where you left it.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "The Permission You Cannot Take Back",
"description": "The FBI is warning Microsoft 365 users about a device-code phish that survives a password reset. Passwordless login moved the lock to a place you can no longer reach.",
"identifier": "PRG-0045",
"datePublished": "2026-06-28T14:05:00.000Z",
"dateModified": "2026-06-28T14:05:00.000Z",
"author": {
"@type": "Person",
"name": "Aldous Renn",
"url": "https://progoff.com/authors/aldous-renn"
},
"publisher": {
"@type": "Organization",
"name": "Progoff",
"url": "https://progoff.com"
},
"image": "https://progoff.com/records/the-permission-you-cannot-take-back/opengraph-image",
"keywords": "custody, permission, credentials, capture",
"articleSection": "Technology",
"url": "https://progoff.com/records/the-permission-you-cannot-take-back",
"mainEntityOfPage": "https://progoff.com/records/the-permission-you-cannot-take-back",
"sha256": "535b78311dff1f0252b01e060eed4ad60c391aaf04945bfdc2109205c7ffcef2",
"creativeWorkStatus": "open",
"isAccessibleForFree": true
}