Harvesting is a read operation, and that is the whole problem. An infostealer running as the logged-in user does not need to escalate privilege or break a cryptographic control. It opens files that the user's own tooling wrote and that the user's own account is entitled to open. GitGuardian's list of targets on a developer machine covers cloud credential caches, .env and config files, shell history, SSH keys, browser tokens and AI tool caches [3]. That is six distinct stores [13], each with a different owner and no shared expiry. The malware makes no phishing attempt at any point [12]. The credential cache is doing exactly what it was designed to do, which is the awkward part.
The 39% deserves the same handling as any benchmark table, because it is a claim about someone else's incident population. Verizon's 2026 Data Breach Investigations Report counts credential abuse across investigated breaches when the full chain is reconstructed rather than the initial access step alone [1]. The post does not split that share between endpoint harvest and lured login [15]. For the figure to say anything about your estate, your incident sample would have to look like Verizon's, and you would need to know which half of the mechanism produced it.
Two of the source's own claims sit in tension. It says the delivery path for adversary-in-the-middle is unchanged, so email security and awareness training work against it much as they do against classic phishing [9]. It also says what genuinely moved the balance is the endpoint, where there is no user to trick at all [10]. Both hold. Read together, they say the awareness line item is defending the vector that most organisations have already blunted [8]. Device code phishing shows how narrow the margin is on that side: the victim approves a legitimate device-authorization request and hands over a fully authenticated session, with the password never typed [7].
If a secret is readable by the account that owns it, the only property left that limits blast radius is how long it stays valid. A static cloud key on a laptop is worth whatever it unlocks until somebody rotates it. A one-hour token is worth an hour. That is the case for pushing local development onto brokered, short-lived credentials, and in my context it is the right trade. The adoption cost is not small. You need a broker or a device-bound login path, every SDK invocation has to go through it, and you will discover the cron job and the CI step that were quietly built on a static key years ago. What you get back is a cheaper rotation drill, because there is less on disk to rotate.
Detection moves too. Harvesting fills the bucket and stuffing replays it against login forms to see which credentials still work [11]. Telemetry pointed only at the replay is watching the second half of the sequence, after the collection succeeded [5].
