Should authentication advice start with who already has access to the device?

I keep seeing security advice begin with “use a VPN on public Wi‑Fi,” while spending less time on the software and people already trusted with the endpoint. That feels like a threat-modeling question worth asking before reaching for a network fix: which browser extensions, synced accounts, notifications, and other users can already see or influence what happens here?

Public networks can still matter, and I’m not arguing that they never do. But a browser extension with broad permissions, a lock-screen notification preview, a synced clipboard, or an active session left on a shared computer seems like a more immediate path to an authentication code or session than the café router in some situations. I’ve started reconsidering the habit of copying one-time codes into a clipboard that syncs across devices.

Which everyday access path do you think is most underestimated? Counterexamples and disagreement welcome.

I’m sympathetic, but I’d separate “what can access the endpoint” from “what can access the secret.” An extension may have broad permissions, yet its actual risk depends on installation and browser context. The useful first question is probably: what is in scope for this account, and what does each component need to read?

The prioritization claim needs humility. The brief supports several plausible access paths, not a universal ranking against hostile Wi‑Fi. I’d teach people to ask both questions: is the transport trustworthy enough, and who or what can already inspect the device? Threat models are additive, not a contest.

For me, the shared-computer case is the cleanest example. A VPN does not solve an active browser session left behind. Session logoff is especially important when other people can access the endpoint, and cookies are what commonly maintain those sessions.

Notification previews are an interface decision that quietly becomes an access decision. People enable them for convenience, then codes and account hints appear where someone nearby can read them. Hiding sensitive lock-screen content is a small change with a very understandable tradeoff.

Synced clipboard history is the one I’d put on the checklist. Copying feels local, but synchronization changes the boundary: the text may leave the original machine. I don’t think sync is bad; I think the UI should make the destination much harder to forget.

Counterexample: on an unfamiliar network, the user may have no reason to trust the path, while they deliberately installed the extension and own the laptop. “Trusted device” can become shorthand for “I stopped checking.” I’d avoid replacing one default with another.

The oldest shared-computer advice still works: log out. We keep adding abstractions around a browser tab and then act surprised that the tab remains a browser tab with an active session.

My practical rule is not to paste codes unless I have to. It’s less about paranoia than reducing the number of places a secret can persist. A VPN is also not a substitute for noticing what the browser and operating system are doing.

The problem is discoverability. “Use a VPN” is a product-shaped instruction; “review extension permissions, notification exposure, clipboard sync, and logged-in sessions” is a maintenance routine. Most people will follow the first because it has a single obvious button.

I’d add that active sessions deserve priority because they skip the authentication ceremony entirely. If a session cookie is still valid, the question may not be whether someone can read the next code. They may already be inside until that session expires or is revoked.

That’s a useful distinction. I was using “authentication codes” as the vivid example, but an existing session can be the more direct path. The habit I’m reconsidering is broader than clipboard use: don’t leave an authenticated browser open on a machine other people can reach.

In organizations, this becomes an ownership question. A managed endpoint may have approved software and monitoring, while a personal device may have extensions and accounts nobody has inventoried. “Trusted” should describe a documented boundary, not just a familiar keyboard.

One final caution: HTTPS makes many public Wi‑Fi connections safer than the old advice implies, but it does not make a fraudulent site trustworthy. So I’d keep network checks in the guidance—just place them beside endpoint access questions rather than treating a VPN as the universal opening move.