Tab Locking vs Password Managers: Why You Need Per-Tab Encryption in 2026

The Missing Piece in Your Browser Defense Model

If you ask security professionals how to secure online accounts, the first recommendation is almost universally: "Use a password manager."

That advice is correct, and I'd give it too. Tools like Bitwarden, 1Password, and Dashlane are genuinely excellent — they generate high-entropy passwords, they keep them in an encrypted vault, and because they match credentials against the exact origin, they quietly refuse to autofill on a lookalike phishing domain in a way no human ever reliably does. If you take one thing from this article and it's "install a password manager," that's a win.

But notice what that entire category of tool is actually built to do: authentication. Getting you in. The vault's job starts when you land on a login form and finishes the instant the server sets a session cookie.

And then it goes to sleep.

Once you're logged into a web application — the AWS console, corporate email, online banking, a shared Google Doc full of salary data — your password manager has no further opinion about what happens in that tab. The session is live. The DOM is rendered. Anyone who can see your screen can read it, and anyone who can touch your keyboard can act as you in it, without ever encountering a password prompt. That's the gap this article is about, and it's the reason I think of tab locking and password management as two different layers rather than competing products.

The Session Cookie Is the Real Credential

Here's the part that I find most people haven't internalised, including some fairly technical people: after you log in, your password stops mattering.

What matters is the session token. When you authenticate, the server issues a bearer credential — usually a cookie, sometimes a token in localStorage or an in-memory JWT — and every subsequent request carries it. The server doesn't re-derive trust from your password on each page load; it just checks the token. That token is often valid for days or weeks. Some services extend it every time you use them, which means an actively-used session can effectively live forever.

Flags like HttpOnly, Secure, and SameSite are real protections, but look closely at what they protect against. HttpOnly stops JavaScript from reading the cookie, which defeats a class of XSS token theft. Secure stops it travelling over plaintext HTTP. SameSite blunts cross-site request forgery. Every one of those defences assumes the attacker is remote.

None of them do anything whatsoever about a person standing at your desk. To that person, the cookie is already in the jar, already being sent, already trusted. They don't need to steal the token — they just need to move your mouse.

This is precisely why the textbook answer has always been "log out and close your tabs when you step away." It's also why essentially nobody does it. Logging out of eleven tabs and logging back into all of them twenty minutes later is an unreasonable ask, so people rationally choose convenience, and the security advice quietly loses. A control that people won't use isn't a control. Tab locking exists because it makes the same threat manageable at a cost people will actually pay: one password prompt, or one fingerprint, on the way back.

Some applications do implement step-up authentication — asking again before you change an email address, add a payee, or rotate an API key. That's genuinely good design, and where it exists it substantially reduces the blast radius. But it's inconsistently implemented, it usually guards only a handful of destructive actions, and it does nothing to stop someone simply reading the confidential thing already on screen. Reading is often the whole attack. I wrote about how far a bystander can actually get in what happens when someone accesses your unlocked browser tabs, and the honest answer is: much further than you'd guess.

The Fundamental Difference

Read that "what it can't help with" row twice. It's the entire argument. These tools fail in opposite directions, which is exactly why running both leaves fewer gaps than running either one twice as carefully.

Four Places the Gap Actually Bites

1. Physical workstation access and shoulder surfing

You step away for coffee. Someone leans over and reads the tab, or opens a new one and inherits every session in the profile. Your password manager will not re-prompt, because from the browser's perspective nothing suspicious happened — a trusted, authenticated session was simply used.

The standard mitigation is the OS lock screen, and you should absolutely use it. But it's all-or-nothing and it's usually on a five-to-fifteen-minute timer, which is a long time in an open-plan office, a co-working space, or a library. It also doesn't help at all in the case where you're sitting right there and just don't want the person next to you reading your inbox.

2. Screen shares and recordings

This one has bitten almost everyone at least once. You share your whole browser window in a Zoom or Meet call, then switch tabs — and for a second and a half, thirty people see a tab title, a bank balance, or a document called Q3-layoffs-draft. Recorded calls make that permanent and searchable. Streamers and anyone who records tutorials live with a much harsher version of this problem; I went through the specifics in screen recording protection: hiding tabs from screen captures.

The failure mode here isn't a lack of care. It's that the sensitive thing has to be pre-emptively neutralised, because by the time you notice, it's already been transmitted.

3. Shared and family computers

On a shared desktop, a single browser profile means a single trust boundary. Whoever sits down next is you. Kids, housemates, and coworkers aren't attackers, but "not an attacker" and "should be able to read your medical records" are different statements. Separate OS accounts are the correct architectural answer, and I'd genuinely recommend them — see shared computer security: the ultimate guide — but on family machines they're often not set up, and on locked-down school or work machines you may not be allowed to create them.

4. Session restore and cross-device sync

Reopen your browser and it helpfully restores everything, still logged in. Now add sync: the tab you had open on your work laptop is one click away on the phone in your bag, or on the home computer your family uses. Sync isn't a flaw — it's the feature — but it does mean the set of screens where your authenticated session can appear is larger than the machine in front of you. I unpacked that expansion of the attack surface in how browser tab sync across devices creates new attack surfaces.

What Tab Locking Actually Does, Technically

I want to be concrete here rather than hand-wave about "encryption," because the implementation details are what determine whether a lock is meaningful or decorative.

It derives a key rather than storing a password. Locksy runs your master password through PBKDF2-HMAC-SHA256 at 600,000 iterations using the native Web Crypto API. The password itself is never written to disk — only the derived material needed to verify it is. The iteration count is the point: it makes each guess in an offline brute-force attempt expensive enough that a weak-but-not-terrible password buys real time. If you want the mechanics, what is PBKDF2 encryption, explained walks through it properly.

It navigates away, rather than covering up. This is the difference I'd look for in any tab locker you evaluate. A lock implemented as a full-screen overlay leaves the original page loaded underneath — still in the DOM, still one Esc or one DevTools node-deletion away from being visible again. Navigating the tab to an internal extension page discards the rendered document instead of hiding it. Same visual result; very different guarantee.

It re-locks on its own. Auto-lock timers handle the case you'll otherwise forget, with media detection so a lock doesn't fire in the middle of a video call. Scheduled Locking covers predictable windows — work hours, overnight — which I find more useful than it sounds, because it's protection that doesn't depend on you remembering anything. There's more on that pattern in browser security on a schedule.

It can cover a domain, not just a tab. Domain Lock matches with wildcard patterns and auto-locks new tabs that hit a protected domain. I'll come back to why that specific behaviour matters more than it appears to.

It unlocks fast enough to actually use. WebAuthn/FIDO2 platform authenticators — Touch ID, Face ID, Windows Hello, or a hardware key — mean returning to a locked tab costs a fingerprint rather than a typed passphrase. Friction is what kills security controls, so this is a security feature, not a convenience feature. Related: how WebAuthn and FIDO2 biometrics are changing browser security.

And Now the Part Most Comparisons Skip: What It Doesn't Do

If I only told you the good parts you'd end up trusting this layer for things it can't carry. So, plainly:

It does not invalidate the server-side session. A locked tab is a tab you can't read. The cookie is still in the browser's cookie store, still valid. Someone who thinks to open a new tab and type the domain gets a live session. This is the single most important limitation to understand — and it's exactly the hole Domain Lock exists to close, because a locked domain locks the new tab too. If you protect individual tabs but not the domains behind them, you've built a control with a doorway next to it. For a truly hostile scenario, ending the session — logging out — is still the only thing that revokes the credential.

It does not survive an attacker with real control of the machine. Someone with your OS account can open chrome://extensions and disable the extension, load the profile from another browser binary, or read the profile directory off disk. Extensions run inside the browser's trust boundary; they cannot defend the boundary that contains them. Full-disk encryption and a locked OS account are the layers that address that, and no browser extension substitutes for either.

It cannot run everywhere. Browsers deliberately forbid extension scripting on privileged pages — chrome:// internals, the extension gallery, some file:// contexts. Tabs on those pages can't be locked, by design, and any product claiming otherwise on Chromium is describing something that isn't allowed to work.

It is not a password manager, MFA, or a phishing defence. It won't generate your passwords, won't notice you're on paypa1.com, and won't stop a credential-stuffing attempt from Belarus. Different layer, different threat.

I'd rather you deploy this knowing the edges. A control you understand precisely is worth more than one you over-trust.

So Which Do You Actually Need?

A password manager, unambiguously, first. If you're choosing between them, choose the vault — remote credential attacks are more common and more scalable than someone walking up to your desk, and reused passwords remain the single most productive attack on the internet. Start with how to create an unbreakable master password, and check whatever you come up with against the password strength checker or just generate one with the password generator.

Add tab locking when your honest answer to any of these is yes:

• Do people walk past, sit near, or share the machine you browse on?
• Do you screen-share, record, or stream a browser window?
• Do you keep long-lived sessions open on accounts where reading the screen is already a breach — health, legal, finance, HR, production infrastructure?
• Are you subject to a rule about unattended sessions — HIPAA, PCI DSS, an internal clean-desk policy?

If all four are no — you browse alone on a machine nobody else touches, and you never present it — a password manager plus a short OS lock timer is a reasonable place to stop. I'd rather tell you that than pretend everyone needs every layer.

And a note for the "passwords are dying anyway" crowd: passkeys genuinely fix authentication, and they're a real improvement. They also don't touch this problem at all, because a passkey's job also ends the moment the session begins. I expanded on that in how passkeys are replacing passwords, and why tab protection still matters.

A Setup That Works Together

Here's the configuration I'd actually recommend, in the order I'd do it:

1. Password manager for every account, unique high-entropy passwords everywhere, and turn on autofill-by-origin. This is the load-bearing layer.
2. MFA — passkeys or an authenticator app on anything that offers it. SMS only if it's the sole option.
3. OS lock screen on a short timer. Five minutes. This is free and it's the layer that survives extension-level bypasses.
4. Domain Lock the handful of domains that matter, not every tab you have open. Banking, email, admin consoles, your HR portal. Locking everything is how people end up turning the whole thing off in week two.
5. Auto-lock at five to ten minutes, with media detection on so calls don't get interrupted.
6. Enrol biometric unlock. It's the difference between a control you keep and one you disable.
7. Use Strict Mode before you present. Smart Sessions keeps you signed into the extension popup between uses; Strict Mode (0 minutes) expires that immediately, and sensitive actions still demand a password or biometric re-auth regardless.
8. Print the Master Recovery Key and store it offline. Because nothing syncs, there is no server-side reset — that key is the only recovery path. A drawer or a safe; not a note in the cloud.

Eight steps, most of them one-time. That's a genuinely layered browser posture, and each layer covers a failure mode the others structurally can't.

Objections Worth Answering

"Just use separate browser profiles."

Good instinct, and profiles do give you real cookie-jar isolation — better isolation than an extension can offer. But they don't lock anything. A profile that's open is a profile that's readable, so profiles partition sessions while tab locking gates access to them. They compose well; neither replaces the other.

"Just lock your screen."

Do lock your screen. But an OS lock is binary and timer-driven: it can't leave your music playing while hiding your inbox, it can't hide one tab from the person you're deliberately screen-sharing with, and on a five-minute timer it leaves a five-minute window every single time you walk away.

"My password manager already auto-locks its vault."

It does, and that's good — but it locks the vault, not your sessions. Bitwarden timing out doesn't log you out of Gmail. That's the whole thesis of this article in one sentence.

"Isn't a browser extension lock just security theatre?"

It would be, if it were sold as protection against a skilled attacker with your machine. It isn't. It's a control against opportunistic local access — the coworker, the housemate, the person behind you on the train, the screen share — and against that threat model it's effective, because those adversaries are not going to open chrome://extensions and reason about your profile directory. Match the control to the threat and it stops being theatre. Oversell it and it starts being a lie.

The Short Version

Password managers protect the door. Tab locking protects the room after you've walked through it. They're solving different halves of the same problem, and the reason the second half gets ignored is that for years the only advice on offer was "log out every time," which nobody follows.

Use both. Understand what each one can't do. And if you only ever act on one line in this article: your session cookie, not your password, is what an attacker in the room is actually using.