Old phones and laptops can stick to an account like spare keys in a junk drawer. I clean them out on a regular basis because unused devices can still trigger sign-in prompts, sync confusion, and security worries.
I see this most after phone upgrades, hand-me-down tablets, and retired work PCs. The good news is that it only takes a few minutes to remove old devices from the big three accounts, and the payoff is immediate.
What I Check Before I Remove a Device
Before I remove anything, I confirm what I’m looking at. Device names can be vague, and an old phone may show up with a model number instead of the nickname I gave it.
First, I check the device activity. If a device hasn’t shown activity in months and I no longer own it, it goes. If I sold it, traded it in, or reset it, I remove it even faster.
I also pay attention to where I’m signed in. If I’m cleaning up accounts while traveling, I avoid public Wi-Fi because fake login pages are still a real risk. Dale’s write-up on public Wi-Fi login page risks is a solid reminder to do account work on a trusted network.
If I spot an unrecognized device, I remove it first, then change your password and review account activity.
That simple habit keeps a small mess from turning into a bigger one.
How I Remove Old Devices From My Google Account
On Google, the path is still simple in March 2026. I open my Google Account Settings, choose Security, scroll to Your devices, and select manage devices. Then I pick the old device and hit Sign out.
On Android, I can do the same thing inside the Google app. I tap my profile photo, open Manage your Google Account for Google account management, choose Security, and then open the Google account list.
Google often says “sign out” instead of “remove,” but the sign out of device process gives the result I want. The old device loses account access. If something looks odd, I change my password right after or move to a stronger sign-in option. This recent Google account cleanup walkthrough matches the flow I’m seeing now.
One small gotcha matters here. A factory-reset device can still appear for a while due to a backend delay. If I know it’s mine and it’s inactive, I sign it out anyway and move on.
How I Remove Old Devices From My Apple Account
Apple is a little trickier because its menus feature two similar device lists. One shows devices signed in to my Apple Account. Another can show devices associated with purchases. That overlap trips up a lot of people.
For the main account list, I sign in to my Apple Account page, scroll to Devices, click the old device, and choose remove from list. If I’m using a newer Apple device, passkey sign-in makes that part pretty painless.
If the device is lost and not simply old, I don’t rush to remove it. I use Find My Device first (and if it’s actually stolen, the option to erase the device), because removal can cut off some tracking and recovery options. Apple explains that clearly in its device list support page.
I also remember that purchase-linked devices can behave differently in apps like Apple Music or Apple TV. So if a Mac or iPhone still appears after I clean up the main list, I check whether it’s tied to purchases rather than still signed in. Apple’s setup feels polished, but this is one place where polished and obvious are not the same thing.
How I Remove Old Devices From My Microsoft Account
Microsoft keeps this direct. I open the Microsoft devices page to view my connected devices, sign in, find the device, open the details menu, and click the remove button or Sign out. After I confirm, the device drops off my list and loses that account tie.
In 2026, the Microsoft your devices page does a better job showing activity details, which helps when I’m trying to decide whether a random Windows laptop is mine or a ghost from years back. The official Microsoft support steps for device removal match what I’m seeing now.
I also remember that this remote sign out improves account security, but removing a device can affect OneDrive sync, Outlook sign-in, and other Microsoft services on that machine. That’s usually the point, but I like to know the splash zone before I click. If it’s a work or school device, I check with IT first because managed systems can follow different rules.
What I Do Right After Cleanup
Once I purge old devices, I don’t stop at the device list. I treat cleanup like locking the door after I bring the spare keys back inside.
First, I review recent account activity and security settings on each account. Then I update my password if anything felt off. Better yet, I move to stronger sign-in methods when I can. Dale’s breakdown of passkeys vs traditional passwords is worth reading if I want fewer password problems across Google, Apple, and Microsoft.
I also sign out of browser sessions I no longer use, especially on shared family computers. Then, as part of my routine Security Checkup, I do a security check to make sure my recovery email, phone number, and trusted devices are current. Otherwise, I can lock myself out while trying to be safer, which is peak tech irony.
A Five-Minute Habit That Pays Off
A stale device list is like that junk drawer from the opening, harmless until I need something fast and can’t trust what’s inside. A quick cleanup to remove old devices and deactivate a device makes my accounts easier to read and much easier to trust.
If I haven’t checked your devices lists on Google, Apple, and Microsoft in the last few months, now’s a good time. How many unknown devices are still riding along in my accounts, instead of keeping an approved list?
When I read the report about a hacking group called ByteToBreach claiming access to systems tied to Sweden’s BankID e-government platform, my first thought wasn’t “wow, hackers.” It was, “this is what happens when identity gets centralized, outsourced, and treated like a convenience feature.”
In plain terms, the attacker claimed a source code leak, grabbing things like source code, configuration files, and staff related data including personnummer, plus materials connected to electronic signing and identity verification. CGI (the vendor in the story) disputed the scope and said the incident involved limited test servers, not live systems. Sweden’s government also confirmed there was a leak, and the incident response team (CERT-SE) is investigating.
That push and pull matters, because the bigger lesson doesn’t depend on who wins the PR argument. The lesson is simple: biometrics don’t belong in government sized databases, or in contractor ecosystems that eventually feed them.
If a password leaks, I change it. If my face or fingerprints leak, I’m stuck with them.
This Story Really Tells Me About Digital Trust
Here’s the 8th grade version of what I took from the CGI Sweden story on digital identity. A big contractor that supports government digital services allegedly got hit, and data that helps run those services may have been exposed. Some sources describe it as e-government platform source code and related documentation. CGI says it was limited and isolated. Sweden says it’s real enough to investigate.
That’s not a niche problem. It’s the most normal kind of problem we have now: supply chain risk.
“Supply chain” in security doesn’t mean trucks and warehouses. It means trusted helpers. A vendor builds the platform. Another vendor hosts it. A third vendor manages logins and identity verification. A fourth handles electronic signatures. If one helper gets compromised, everyone downstream can feel it.
Reporting around this incident highlights the concern that even “just” source code and configs can be a roadmap for attackers later. If you want context on what was reportedly involved and how Sweden responded publicly, this summary is a decent starting point: Sweden probes reported leak of e-government platform source code.
And since BankID sits in the same neighborhood of digital trust governed by the eIDAS regulation, people naturally asked the scary question: “Was BankID breached?” Several writeups stress that BankID itself wasn’t directly attacked. Still, the ecosystem around identity matters because attackers don’t always punch the front door. They look for a side door.
Even If BankID Wasn’t Breached, The Ecosystem Still Got Weaker
A modern digital identity system is like a theme park wristband. You tap it at the gate, the ride, the snack bar, and the locker. That’s convenient for fraud prevention, until someone figures out how the wristbands are made, validated, or reset.
Even if the “main system” stays intact, leaked source code and configuration details can help attackers in three practical ways:
First, they can study how the platform is supposed to work, then look for mistakes that weren’t obvious before. Second, they can craft scams that sound real because they know the internal language, the file names, and the workflow for services like remote onboarding. Third, they can hunt for similar systems that were deployed with the same settings, because reuse happens everywhere.
Biometrics Aren’t Like Passwords, Once They Leak, You’re Stuck With Them
When people say “biometrics,” they usually mean biometric verification with face scans, fingerprints, and sometimes iris scans. The pitch is always the same: it’s quick, it’s easy, and it’s “more secure.”
Sometimes it is more secure, but only in a narrow sense. A fingerprint is harder to guess than “Password123.” That’s true. The trade is that your fingerprint is also not replaceable.
I’m fine using biometrics on my own device when they stay on my device, especially with multi-factor authentication. That’s one reason passkeys are interesting. With passkeys, your face or fingerprint acts as an unlock button for a cryptographic key stored locally. That’s very different from sending a reusable biometric token into a large system like Estonia e-ID. I broke that down in my post on passwordless passkeys using biometrics, and it’s a distinction I wish more policies made clearer, particularly for identity verification.
A national ID system that trends toward face matching raises the stakes. It turns “proof of you” into “a permanent identifier that might get copied, stolen, or repurposed.”
A password is a coat you can change. A biometric identifier is your skin. Treat them differently.
Why I Don’t Want My Biometrics Stored Or Normalized By Any Government Entity
I’m not anti-ID. I travel. I show my ID. I’m not trying to make an officer’s job harder.
My line is simpler: I don’t want my face to become the default ticket to move through public life via identity verification at checkpoints. Once we normalize digital identity programs like that, it spreads. It spreads because it’s “efficient,” because a vendor already has the cameras, because budgets are easier than policy debates, and because most people don’t want to argue at a checkpoint.
The problem is that government digital identity programs using biometrics tend to attract four forces that don’t care about my preferences:
Permanence. Biometrics don’t rotate like passwords, so any breach exposing personally identifiable information has a long tail.
Purpose creep. A system built “just for travel” starts showing up in other places, like mobile driver’s license apps. That’s not a conspiracy, it’s how budgets get justified.
Contractor sprawl. Even if the government writes good rules, it still relies on vendors, subcontractors, and integration partners. The Sweden story with agencies like Bolagsverket and Skatteverket is a reminder that the weakest link might not be the agency itself.
Chilling effects. When facial recognition with liveness detection becomes automatic, people change how they behave. It’s subtle, but real.
I also don’t accept “trust us” as a security plan. Agencies can promise deletion timelines and narrow use cases. Policies can also change. Leadership changes. Laws change. Contractors change. Meanwhile, the database keeps existing.
“Temporary” Programs Have a Habit of Becoming Permanent
The most common pattern I see is the “optional first” rollout.
It starts at a handful of locations. Then it expands. Then the signage gets vague. Then the staff gets trained to keep the line moving, not to explain choices. After a while, opting out feels like you’re asking for a favor.
Some traveler advocacy groups say that’s already happening with TSA airport face scans, mainly because people aren’t clearly told they can refuse. The Algorithmic Justice League has been collecting traveler experiences and pushing the message that you still have a choice. Their campaign page is here: You can opt out of TSA face scans.
Centralized Identity Plus Biometrics Raises the Stakes for Everyone
A single login for many services sounds great until you picture failure modes.
If identity is used for banking, benefits, healthcare portals, travel, and document signing, then one breach is no longer “just” one breach. It’s the key ring.
That’s also why vendor incidents bother me more than one-off hacks. When contractors build shared plumbing for many agencies, the blast radius grows. Even if the leaked system is “just a test environment,” people reuse patterns, code, and settings. Attackers know that.
So when I hear “it’s only for convenience,” I translate it to, “we’re building a reusable mechanism to identify you everywhere.” Convenience is real, but so is the risk.
I Opt Out at Airports and Customs, and You Can Too (In the US)
This is the section I wish someone had handed me years ago.
When a camera shows up at the TSA checkpoint and an agent gestures for me to look at it for facial recognition, I opt out. I do it politely. I do it every time. I do it even when I’m tired, because practice is the whole point.
Here’s what I’m trying to avoid: a world where facial recognition becomes the default, and opting out becomes suspicious behavior. I’d rather make opting out normal while it’s still allowed and relatively easy. This keeps me away from biometric verification altogether.
I also plan extra time. TSA manual lanes can take longer during rush periods. That’s not a punishment, it’s just reality when most people flow through the automated path, complete with liveness checks and QR code scanning for phone-based boarding passes.
And while this post focuses on the US, the principle travels well: you don’t have to hand over more identity data than the situation requires. An ID check is one thing. A reusable biometric record is another.
One extra travel tip while we’re here: airports are a perfect place for digital scams too. If you’re killing time on public Wi-Fi, read my guide on captive portal attacks on airport Wi-Fi. Identity and connectivity risks love the same crowded spaces.
What I Say, Word for Word, When They Ask for a Face Scan
I keep it short. I don’t debate. I don’t explain my politics. I just state a preference.
Here are the exact phrases I use:
“I’d like to opt out of biometric screening, please.”
“I prefer a manual ID check.”
If the agent asks “why,” I don’t take the bait. I just repeat the request. In most cases, the TSA process shifts to the standard manual identity verification, my physical ID, my boarding pass if needed, and the officer looking at my face like we’ve done for decades.
If They Pressure Me, Here’s How I Hold the Line Without Escalating
Pressure usually looks like speed, not threats. The line is moving, the agent sounds annoyed, and you feel like you’re holding everyone up. That’s the moment most people comply.
When that happens, I do three things:
I slow my voice down and stay calm. Tension feeds tension.
I repeat the same sentence. Short and boring wins: “I’d like to opt out and do a manual check.”
If needed, I ask for a supervisor. I keep it neutral: “Can you call a supervisor to help me with the TSA opt-out process?”
I don’t argue about facial recognition accuracy, bias, or policy at the podium. That’s not the time. The point is to complete travel and keep your boundary.
Opting out isn’t about causing a scene. It’s about refusing to make biometric collection the default.
The UK’s 2025 Digital ID Push Shows Resistance Works, and Opting Out Is a Form of It
People sometimes tell me, “It’s inevitable.” I don’t buy that.
A good counterexample is the UK’s 2025 digital identity push that heated up in 2025. The plan connected to GOV.UK services and the One Login program, and it triggered a familiar set of concerns: privacy, security, governance driven by KYC AML compliance, and what “optional” would really mean in practice.
The key point for me is this: public skepticism slowed things down. It forced consultation. It made officials explain limits instead of rushing a mandate.
As of March 2026, the UK government is still publishing consultation materials about digital identity, which signals this hasn’t become a simple, settled rollout focused on identity verification to make public services work for citizens. You can see that framing in their own words here: Making public services work with your digital identity.
### When Enough People Say “No,” Mandatory Plans Turn Into “Optional” Ones
Public pressure doesn’t always kill a proposal. Sometimes it reshapes it.
That reshaping matters. It can mean longer timelines, tighter rules on beneficial ownership and governance, clearer opt-outs, or stronger oversight. It can also mean a change in messaging, because the “we’re doing this for fraud prevention and to fight identity theft” pitch often lands badly. Governments then pivot to “convenience,” like digital wallets or initiatives such as Secure Start, because convenience is easier to sell.
In other words, resistance works even when you don’t get a dramatic headline, much like the challenges seen in large-scale biometric ID systems such as India’s Aadhaar program.
Opting out at airports is the same kind of resistance, just quieter. Every opt-out is a signal that people want an alternative lane that respects privacy.
My Goal Isn’t to Avoid ID Checks, It’s to Avoid Permanent Biometric Tracking
I want to be crystal clear: I’m not trying to evade identity checks. I’m trying to avoid turning my face into a reusable key that gets scanned, logged, stored, or shared beyond the moment.
The Sweden incident claim (and CGI’s response) is a reminder that even wealthy countries with mature infrastructure still deal with leaks and vendor risk. When those systems include biometric identifiers, the cost of failure isn’t just high. It’s personal.
So I draw a line where it counts: I’ll prove who I am, but I won’t help normalize biometric collection as the default.
Conclusion
The CGI Sweden leak claim involving BankID and e-government services is a warning about how messy digital identity ecosystems get when vendors, code, and electronic signature workflows stack up. Add biometrics to that mix, and every breach becomes harder to recover from, because you can’t replace your face like a password.
In the US, opting out of airport face scans is a real choice many travelers still have, so I use it. Next time you fly, try it politely, plan a little extra time, and tell one other person they can opt out too. If enough of us keep choosing privacy, “scan first” won’t quietly become the new normal.
These phishing scams use fake pop-ups that are getting better at acting like your computer is screaming for help. One minute you’re reading the news, the next you’re staring at a “virus detected” pop-up warning that feels way too real.
Here’s the bottom line: fake security alerts are built to rush you. They want a click, a call, or a payment before you slow down and think. In this guide, I’ll show you the tells I look for on Windows and macOS, plus what I do the moment one shows up (without turning it into a bigger mess).
What Fake Security Alerts Are Really Trying to Do
A legit security alert helps you make a safe choice. A scam alert tries to make the choice for you, right now, while you’re stressed, using scare tactics.
Most fake security alerts fall into a few buckets:
Browser pop-ups, such as fake antivirus alerts, that pretend to be Microsoft, Apple, or “your antivirus.”
Push notifications you accidentally allowed from a sketchy website.
Email or SMS warnings claiming your account was hacked or billed.
“Cleaner” apps that show scary results, then demand payment to “fix” them.
In March 2026, I’m still seeing the classic tech support pop-up scam where a page claims your PC is infected with scary-sounding malware names, then shows a phone number and tries to keep you trapped in the tab. Some even fake a “command prompt” style scan to look official. Guardio has a clear breakdown of the pattern and safe next steps in their write-up on the tech support pop-up scam warning signs.
These scams rely on social engineering, the psychological manipulation that powers such traps. If you want a simple definition to share with a parent or a coworker, Savi Security’s glossary entry on what a fake alert is nails the idea: it’s fear as a user interface.
A real alert gives you options. A fake warning gives you urgency.
Common Signs of Fake Antivirus Alerts on Windows
Windows is the most impersonated target, mostly because the “Microsoft support” storyline still works on a lot of people.
Here’s what makes me label a Windows warning as fake warnings fast:
First, it’s inside the browser. The page may go full-screen with a system scan animation, flash, beep, or block right-click. That’s theater. Microsoft Defender does not need a random webpage to do its job.
Next, I watch for the “call now” move. Any pop-up that includes a tech support number for “Windows Support” is almost always a scam.
Also, the language gives it away. Scam alerts love phrases like “your computer is blocked” or “network breach detected,” plus countdown timers. Real Windows security messages tend to be calmer, and they don’t threaten you like a movie villain.
Finally, pay attention to what it asks you to do. A scam often pushes one of these actions:
Call a number.
Download a “security tool.”
Allow notifications.
Pay to remove threats.
If you want a deeper scam-adjacent example, fake alerts often show up on hostile Wi-Fi too, when a bad network injects junk pages from malicious websites or redirects through suspicious links. That overlaps with the same instincts I use to spot fake Wi-Fi login pages when I’m traveling.
Red Flags on macOS That I Don’t Ignore
Mac users get hit with fake security alerts too, just packaged differently. These fake antivirus alerts usually pretend your Mac has a “virus infection” and your “Apple security” subscription is expiring, then it pushes you to call or pay.
Here are the macOS tells I rely on:
A big one is the wrong app source. If the pop-up warnings appear in Safari or Chrome, it’s not a macOS system alert. It’s a website doing impressions.
Another clue is the “virus found” notification that wants money fast. macOS does have built-in protections, but it doesn’t pop up and demand $5.99 to save you.
I also look for weird wording and generic branding. Scam pages mix “Apple,” “iCloud,” and “MacOS” in ways Apple never does. They aim to steal your personal information and may also claim your “IP has been hacked,” which is a phrase that sounds technical but means nothing useful.
If you want to see how common this panic is, there’s a very real thread on the Apple forums where a user asks about recognising fake virus notifications on a MacBook. The details change, but the emotion stays the same: fear, urgency, and a payment prompt.
What I Do Right Away When a Fake Alert Pops Up
Panic makes people click. My goal is to break the spell and get back in control.
Here’s my routine, in order, because order matters:
Don’t click inside the alert. Not “OK,” not “Cancel,” not the phone number.
Force-close the browser/app. On Windows, I use Task Manager. On macOS, I use Force Quit.
Reopen the browser while holding safe habits. If the same tab tries to restore, I refuse it. I start a fresh session instead.
Check for notification permission abuse. If a site can send notifications, I remove it right away in browser settings, and I verify that the pop-up blocker is enabled.
Run a real scan. On Windows, I use security software like Microsoft Defender. On macOS, I check Applications and browser extensions for anything I didn’t install.
If the alert wants you to call someone, it’s almost never real support. It’s a trap door.
If I Already Clicked or Called, I Switch to Damage Control
If you clicked a download, entered personal information like a password, or called the number, don’t spiral. Act like you spilled something on the keyboard: stop the spread, then clean up.
If you gave remote access (ScreenConnect, AnyDesk, TeamViewer, “Quick Assist”), disconnect from the internet first. Then remove the remote tool, reboot, and change passwords from a different device you trust.
If money or financial information got involved, treat it like fraud, because it is. The next steps overlap with my general advice on how to avoid online money scams, including calling your bank and disputing charges fast.
Security Hero also documents how these pop-ups work and why calling is where the real damage starts in their guide on tech support scams.
How I Prevent Fake Security Alerts From Coming Back
Once you’ve seen one scam pop-up, you start noticing how often the web tries to “ask permission” for stuff it doesn’t need.
I start with browser housekeeping through smart browser settings. I clear suspicious site data, remove extensions I don’t recognize, stay on top of software updates, and shut down notification permissions for anything that isn’t a site I trust.
Next, I make my logins harder to steal. A lot of these scams don’t need malware at all; they just target credential theft and account hijacking, which can lead to full identity theft. That’s why I’m a fan of passkeys, because they’re tough to use on look-alike sites, and I follow up with multi-factor authentication plus email authentication for extra protection. If you want the practical version, I put it all in my guide to phishing-resistant passkeys explained.
Finally, I teach one simple rule at home: if a screen claims “call now” or “pay now,” you stop and ask a human you trust. Scammers hate speed bumps. Even a 30-second pause ruins their plan. These habits build lasting digital safety.
Conclusion
Fake pop-ups work because they feel urgent, not because they’re smart. When I spot fake security alerts, I focus on the source (browser vs system), the ask (call, pay, download), and the tone (threats and timers) typical of fake warnings. If you take one habit from this, make it this: close the app safely and verify using real tools, not the scary window in front of you. The next time your screen “yells,” you’ll know how to tell if it’s a real smoke alarm or a phishing scams sound effect.
OpenClaw (formerly Clawbot and Moltbot) keeps popping up in my DMs. Friends, family, parents in my neighborhood, and security folks I work with all ask the same thing: “Is it safe to run an AI assistant that can actually do stuff?” Here’s my honest take on OpenClaw security and secure deployment: OpenClaw is impressive because it is an autonomous AI agent that turns a chat message into real actions. But anything that can touch files, browsers, and commands deserves grown-up security. “Convenience is great until it becomes an open door”.
So in this post, I’m going to share how I test OpenClaw in a way that keeps it off the public internet. I’m also going to explain why I personally like Twingate for this, because it lets me keep ports closed while still getting secure remote access.
What OpenClaw Is Great At, And Why That Also Makes It Risky
OpenClaw is a self-hosted AI agent. In plain English, that means it’s a “do-er,” not just a “talker.” You chat with it in an app, and it can run skills that perform real tasks, like updating files, calling APIs, or automating a browser session.
When I say “agent,” I mean software that can take a goal, plan steps, and then act. When I say “skills,” I mean plug-in abilities you enable, like file access or shell commands. If you want a deeper, plain-language rundown of what agents are and why they matter, I wrote AI Agents Explained for 2025 Workflows.
That power is also the risk, especially when considering OpenClaw security and secure deployment.
If OpenClaw can run tools, then a bad prompt, a poisoned skill, or a stolen key can turn “helpful assistant” into “tiny intern with admin access and no fear.” The most common threats aren’t sci-fi. They’re the same boring problems we’ve always had, just with better automation and added runtime risk:
Prompt injection: Trick the agent into ignoring your rules and doing something unsafe via untrusted input.
Prompt injection through authentication bypass: An attacker crafts input to override safeguards and access restricted actions.
Stolen API keys: If someone gets your model tokens, they can burn money or pull data.
Unvetted skills: A skill can be buggy, over-permissioned, or flat-out malicious, enabling remote code execution or data exfiltration.
Accidental exposure: One port-forward, one rushed firewall rule, and you have exposed instances vulnerable on the internet.
My rule: treat OpenClaw like shadow AI that can touch real systems in your home network, because it can. Testing safely beats being fearless.
The Two Ways People Get Burned: Public Exposure And Over-Permissioned Tools
Most “I got wrecked” stories fall into two buckets.
First, public exposure. Someone opens an inbound port for convenience. Maybe it’s SSH, a dashboard, or the OpenClaw gateway itself. The thought process is always the same: “It’s just for a day.” Then life happens, the port stays open, and scanners find it.
Second, over-permissioned tools. People enable the scary skills because they’re fun. Shell access, full disk read and write, browser control, and broad network reach. Then they install a skill they didn’t review, or they paste something into chat that the agent interprets in a surprising way.
Here’s the cause and effect in one sentence: the internet will eventually talk to your agent, and your agent will eventually do what it’s allowed to do.
If you want to see how the broader community is thinking about hardening, I’ve skimmed a few guides, and the most practical one I’ve seen is OpenClaw hardening steps. I don’t agree with every choice, but the defensive mindset is right.
My “Safe Sandbox” Setup For Playing With OpenClaw
When I test OpenClaw (or, for that matter, any new tool), I focus on security and secure deployment. I build in a sandbox mode that assumes something will go wrong. Not because I’m pessimistic, but because it’s cheaper than cleaning up later.
My baseline looks like this:
I run OpenClaw on a spare machine, a VM, or a container. I keep it away from my personal laptop files, family photos, password vault exports, and work credentials. “If I wouldn’t hand it to a stranger at a coffee shop, I don’t mount it into the agent environment”. This setup works well for ecosystem components like OpenClaw.
Next, I keep the OpenClaw gateway bound to localhost. That’s a big one. Localhost means it only listens to itself, not your whole network, and definitely not the internet. If a service must be reachable, I want it reachable through an access layer, not by opening a port and hoping for the best.
I also keep persistent memory and logs locally while I’m learning. I don’t push agent logs into random cloud dashboards on day one. Logs can contain prompts, tokens, filenames, and other “oops” data you did not mean to share.
Containment First: VM Or Container, Limited File Access, And No “God Mode” Accounts
Containment is me asking, “If OpenClaw gets tricked, what’s the blast radius?”
So I start with virtual machine isolation or a container and a dedicated non-admin user. I avoid running anything as root unless I have a clear reason. For file access, I prefer narrow mounts. If the agent needs a folder, it gets one folder, not my whole home directory.
I also keep risky tools disabled at first. Shell execution, shell commands, broad file search, and browser automation are powerful, but they’re also easy to misuse. I turn them on only when I need them, and I turn them back off when I’m done testing that feature.
Gotcha: the “cool demo” permissions are almost never the “safe default” permissions.
Credential Hygiene: API Keys, Tokens, And Skill Review Without Paranoia
Secrets are where most lab setups get sloppy.
I don’t hardcode API keys, SSH keys, or OAuth credentials in plain-text files next to the app. Instead, I use environment variables, or a secrets manager if the setup warrants it. I also keep separate keys for lab vs production. That way, if my test box gets popped, the attacker doesn’t inherit my real-world access.
Rotation matters too. If I’ve been experimenting for a week and sharing screenshots, I assume a key might have leaked. Then I rotate it and move on.
Skills get a quick review with the Skill Scanner (https://clawned.io/), especially those pulled from ClawHub. I’m not doing a full code audit every time, but I do skim for obvious red flags: surprise network calls, broad file permissions, and anything that shells out without guardrails. Info-stealers love config folders, so I treat that directory like it’s sensitive.
For a more “setup-focused” angle (especially if you’re still learning the moving parts), this OpenClaw setup guide is useful background reading.
How I Secure Remote Access With Twingate, So I Don’t Need Public Ports Or A VPN
At some point, you’ll want to use OpenClaw when you’re not at home. That’s where people get tempted to punch a hole in the firewall.
I don’t do that!
Instead, I use Twingate (https://www.twingate.com/) as my preferred way to reach internal resources without exposing them, ensuring OpenClaw security and secure deployment. The core idea is simple: authenticate and authorize every connection, and keep the private service private. From my perspective, the big win is no inbound firewall rules. The connector makes outbound connections, providing network isolation so I’m not publishing a new target to the world.
This is also why I don’t start with a traditional VPN like ExpressVPN for this use case. VPNs can be fine, but they often feel like giving someone a wristband for the whole venue. For a more general comparison, I’ve got thoughts on that in best VPNs for secure remote access, but my OpenClaw stance is tighter access, smaller blast radius.
The Simple Mental Model:Localhost Gateway, Outbound Connector, And Policy-Based Access
I think about it like a locked door with a guest list.
OpenClaw stays on localhost with gateway binding (for example, 127.0.0.1:18789, but use whatever your OpenClaw config sets.) A Twingate Connector sits inside my network and phones out. My devices use the Twingate Client, and I only allow access to the specific resource and port I choose, leveraging this gateway binding for secure localhost exposure.
In Twingate terms, I’m working with a few building blocks:
Connector: The piece that lives in my network and creates outbound connectivity.
Client: The app on my phone or laptop that proves it’s me.
Resources: The internal things I want to reach, like the OpenClaw gateway that implements the Model Context Protocol for agent communication.
Policies: The guest list, which says who can access what, and under what conditions.
Because nothing has to listen on the public internet, scanning bots can’t even knock.
The Policies I Use: Groups, MFA For Anything Serious, And Logging I Actually Review
Policies are where the safety really shows up.
I assign access by group instead of building one-off exceptions, effectively creating an allow-list. For anything tied to sensitive data, I require MFA. If OpenClaw is allowed to touch even mildly important systems, MFA is non-negotiable. Even with this setup, remote access doesn’t solve issues with untrusted input.
Then I turn on logging and actually look at it. I’m not staring at dashboards all day, but I do check for weird access patterns, like odd hours, unknown devices, or repeated connection attempts that don’t match my habits. I also monitor Connector health, because availability signals can double as security signals. If the Connector flaps, I want to know why.
If I’m going to run an AI agent, I want receipts!
Conclusion
OpenClaw is a powerful autonomous AI agent, which is why I treat it as a tool that can interact with real systems. My three guardrails stay the same: isolate the environment, minimize permissions and credentials to prevent risks like credential dumping, and avoid public exposure by using Zero Trust access (Twingate is my go-to for that).
This guide on OpenClaw security and secure deployment emphasizes starting small, keeping risky skills off at first, and proving your setup is safe before you expand it. If you’re running OpenClaw already, I’d love to hear what you’re using it for, and what part you want to lock down next.
If passwords feel like house keys you’ve copied a hundred times and tossed into a dozen junk drawers, you’re not imagining it. Passwords get reused, guessed, phished, and leaked, then we all get stuck playing the reset game at 2 a.m.
That’s why passwordless passkeys are such a big deal, marking the transition to a modern login standard. They let me sign in using my device (and biometric authentication with my face, finger, or PIN) instead of typing a secret string that can be stolen. Better yet, passkeys are now a first-class login option for Google, Apple, and Microsoft accounts as of March 2026.
In this post, I’ll explain what passkeys are, how they work, and what setup really looks like across the big three. I’ll also cover the parts that can surprise you, like recovery and shared devices.
What Passwordless Passkeys Are and Why They Beat Passwords
A passkey is a login credential built on public-key cryptography from the FIDO Alliance (often described under the FIDO2 and WebAuthn standards). That sounds intense, but the day-to-day experience is simple: you choose a passkey at sign-in, your device asks for Face ID, Touch ID, fingerprint, or a device PIN, then you’re in.
Here’s the key idea: a passkey can’t be “typed” into a fake site. With passwords, a phishing page just needs to look convincing long enough for you to hand over the goods. With passkeys, the sign-in is tied to the real site’s domain, so the fake page can’t trick your device into completing the login the same way, making passkeys phishing resistant.
Also, your biometric data isn’t getting shipped off to Google or Apple or Microsoft. Your face or fingerprint is just the “unlock button” for a cryptographic key stored on your device. The site never receives your fingerprint. It receives proof that your device has the right key.
So why are passkeys showing up everywhere now? Because they reduce two ugly problems at once:
Phishing gets much harder because there’s no password to steal and replay.
Credential leaks hurt less because servers store public keys, not reusable secrets (passkeys also thwart credential stuffing attacks that automate mass logins with stolen credentials).
Passwords aren’t dead yet, but passkeys are finally practical for normal people, not just security nerds.
How Passkeys Work When I Tap “Sign In” (No Math Required)
When I create a passkey for an account, my device generates a pair of keys:
A public key that the service can store.
A private key that stays on my device (or in my device’s synced credential manager).
During login, the site sends a challenge. My device signs it using the private key, after I complete user verification to unlock that key with Face ID, Touch ID, a fingerprint scan, or by entering my screen lock PIN. This is asymmetric cryptography at work. The site checks the signature with the public key it already has. If it matches, I’m authenticated.
That’s it. No shared secrets. Nothing reusable for an attacker to copy-paste later.
I explain it to families like this: a password is like telling the bouncer a phrase. A passkey is like showing up with a tamper-proof badge that only works at the right door, in the right building. A scammer can copy your phrase. That same scammer can’t copy your badge from across the street.
One more detail that matters: passkeys often sync. That’s why they feel “magical” after you set them up on one device. Apple syncs them through iCloud Keychain (now surfaced in the Passwords app). Google syncs them through Google Password Manager. Microsoft can store and use them through Windows Hello and the Microsoft Authenticator app, depending on platform and account type.
If you remember one thing, make it this: passkeys protect you from the “I typed my password into a perfect fake” problem, because the login is bound to the real site.
Passkeys on Google, Apple, and Microsoft Accounts (What Setup Looks Like in 2026)
The good news is that Google, Apple, and Microsoft all support passkeys broadly now. The “gotcha” is that each one stores and syncs them a bit differently, so the experience depends on what devices you actually use.
Before I get into each provider, this is the basic flow I see most often:
I sign in normally once (or confirm it’s me).
The account prompts me to create a passkey.
My device asks for Face ID, Touch ID, fingerprint, or device PIN.
Next time, I pick passkey and confirm with biometrics.
Google Passkeys (Google Account and Gmail)
As of early 2026, Google passkeys work on Android 9+, ChromeOS 109+, and on Apple devices when you use Chrome. They save to Google Password Manager, which can sync across your signed-in devices.
In practice, I’ll create a passkey from my Google account security settings or when Google prompts me during sign-in. After that, the login is usually: enter my email address, then approve with my phone’s fingerprint or face unlock. On laptops, it often hands off to my phone or uses a local method if supported.
Where Google shines is friction. If you’re already living inside Android and Chrome, passkeys can feel like the default fast path.
Where people trip up is mixed-device life. If your day is “Windows laptop at work, iPhone at home,” you’ll still get passkeys working (with a QR code for cross-device sign-in on non-Android hardware), but you may see more QR handoffs and device prompts.
Apple supports passkeys on iOS 16+ and macOS Ventura+. They’re stored in Apple’s credential system and show up in the Passwords app, syncing through iCloud Keychain (end-to-end encrypted, assuming you use it).
For most people, Apple makes passkeys feel invisible. I’ll be on Safari, I’ll tap “Continue with passkey,” Face ID pops, and I’m done. On Mac, Touch ID and the system login prompt handle it.
The best part is consistency. The same Face ID you already trust for unlock and Apple Pay becomes the approval for sign-in. That’s comforting for parents and non-technical users because it feels familiar.
The main limitation is the same one Apple always has: you’ll get the smoothest ride inside the Apple ecosystem. If you bounce between Apple hardware and non-Apple devices, you can still use passkeys, but the handoff steps matter more.
Microsoft Passkeys (Microsoft Account, Windows Hello, Authenticator)
Microsoft supports passkeys on Windows 10+ (and Windows 11), plus mobile support through Microsoft Authenticator on iOS 17+ and Android 14+ in common setups. On Windows, Windows Hello becomes the star of the show (face, fingerprint, or PIN).
In real life, this means I can sign into my Microsoft account and approve with Windows Hello, without ever typing a password again on that device. On mobile, I may create and use these digital credentials through Authenticator, which is also handy when I’m signing into Microsoft services on another device.
Microsoft’s world has two flavors: personal Microsoft accounts and work or school accounts tied to Microsoft Entra ID. FIDO2-based passkeys are showing up in both, but your organization can set rules. If you’re a security pro reading this, that policy angle is where your rollout plan lives or dies.
If you want a quick comparison mindset for whether passkeys replace passwords outright or sit beside them for a while, this guide on passkeys vs passwords and what changes summarizes the tradeoffs clearly.
The Stuff People Don’t Tell You: Account Recovery, Backups, and Shared Devices
Passkeys feel like magic right up until the day you lose your phone, break your laptop, or need to sign in on a borrowed device. Then you find out whether you planned the account recovery “what if” part.
Here’s how I keep it sane.
First, I treat passkeys as the primary login, not the only login. Most services still keep passwords as a fallback, and that’s fine. It’s like having a spare key in a lockbox. I just don’t want that spare key to be my daily routine.
Second, I keep strong account recovery options. That usually means up-to-date recovery email and phone, plus more than one trusted device where possible. For high-security accounts, device-bound passkeys or physical security keys add an extra layer since they don’t sync across devices. If you only have one device that can approve logins, you’ve built a single point of failure.
Third, I think hard about shared devices. A family iPad, a classroom Mac, a lab PC, these can get messy because the passkey is protected by whoever can unlock the device. If your kid knows the tablet PIN, they may also be able to authenticate you in some contexts. That’s not always a disaster, but it’s something to decide on purpose.
This is also where classic multi-factor authentication guidance still matters. Passkeys reduce phishing risk, but I still want layered protection for important accounts, especially when recovery paths get involved. If you need a refresher, I’ve got a straight talk version of two-factor authentication basics that explains why extra factors still help.
One more “real world” warning: public Wi-Fi login pages are a favorite trap for credential theft. If a hotel portal ever asks for your Google, Apple, or Microsoft password, I treat that as a giant red flag. Passkeys help here because you’re less likely to type anything secret into a fake page, but you still need to recognize the setup. My deeper breakdown on spotting fake Wi-Fi login pages is worth a quick read if you travel.
Passkeys reduce risk, but recovery settings decide how bad a bad day becomes.
How I Recommend Switching to Passkeys Without Breaking Your Life
I like passkeys, and I’m using them more every month as part of the broader shift to passwordless authentication. Still, I don’t treat this like a switch I flip once and forget. I treat it like upgrading the locks on my house while I’m still living in it.
My practical approach looks like this:
I start with my most abused accounts: email and cloud identity. That’s Google, Apple ID, and Microsoft. Those accounts often reset everything else, so they deserve the strongest login with passkeys.
Next, I set passkeys on at least two devices when I can, using CTAP so they communicate securely to complete a login. For example, phone plus laptop, or phone plus tablet. That way, a lost phone isn’t an automatic crisis.
After that, I clean up my password habits instead of pretending passwords are gone. A password manager still matters for the many sites that don’t support passkeys yet. Also, I keep unique passwords for the services that remain password-based.
Finally, I keep 2FA enabled where it makes sense, especially on social accounts that get targeted for takeovers. If you want a quick walk-through for the apps families actually use, this guide to set up 2FA on social media is a solid weekend project.
For the “are we really near the end of passwords?” angle, I like this perspective on the rise of passwordless authentication in 2026. It matches my take: passkeys are the direction, but the transition to passwordless authentication is uneven.
Conclusion
Passwords had a long run, but passwordless passkeys are the first replacement that feels both safer and easier. Google, Apple, and Microsoft now support them widely, so you can use face recognition, a fingerprint sensor, or device PIN to sign in without handing attackers something reusable. My advice is simple: enable passkeys for your core accounts, set up recovery like you mean it, and keep a password manager for the rest. If you do that, you’ll spend a lot less time resetting logins, and a lot more time actually using your tech.
You know that moment when you connect to “Free Airport Wi‑Fi” and a page pops up asking you to accept terms? That page is a captive portal, and most of the time it’s harmless. Still, it’s also a perfect place for scammers to set a trap.
Captive portal attacks are sneaky because they don’t need to “hack” your phone in a movie-style way. They just need you to trust the wrong Wi‑Fi network, then hand over something valuable on a look-alike login page.
I travel, teach, and troubleshoot security issues for a living, and public Wi‑Fi is one of those “it’s fine until it isn’t” situations. Here’s how captive portals work, how attackers fake them, and what I watch for in airports and hotels.
What a Captive Portal Really Is (And Why It Exists)
A captive portal is a web page you’re forced to see before the network lets you browse normally. It’s basically a bouncer at the door.
On legitimate networks, captive portals are used for things like:
Accepting terms and conditions
Entering a room number and last name (common in hotels)
Paying for access, or entering a voucher code
Tracking usage or limiting time per device
The important part: a captive portal is not “the internet.” It’s just a local web page served by whoever controls the Wi‑Fi. That’s why it’s such an attractive target.
How Captive Portal Attacks Work in Airports and Hotels
When I explain this to non-security friends, I use a coffee shop analogy.
A real captive portal is the cashier asking for payment. A fake captive portal is someone in a convincing apron standing near the line, taking credit cards, and smiling as if they belong.
Most captive portal attacks start with one of these setups:
The “Evil Twin” Wi‑Fi Network
An attacker creates a Wi‑Fi network that looks official, for example:
“Airport Free WiFi”
“Hotel Guest”
“Marriott Bonvoy WiFi”
“Hilton Honors 5G”
Your device sees a strong signal, you tap it, and you’re connected to the attacker’s access point instead of the real one.
Sometimes they even add a second network with a similar name, counting on you to pick the wrong one when you’re tired, late, or juggling kids and luggage.
The Fake Captive Portal Page
Once you connect, the attacker redirects you to a page that appears to be a normal “Sign in to Wi‑Fi” screen. Then they ask for something they shouldn’t need, like:
Your email and password (especially a Google, Apple, or Microsoft login)
A “work login” prompt
A request to download an “internet certificate,” profile, or app
If you enter credentials, the attacker can steal them. If you install something, things can get worse fast.
The Quiet Part, Traffic Snooping
Even if you don’t type a password into the portal, a hostile network can still watch and manipulate traffic in certain cases, especially if a site isn’t using HTTPS correctly.
This is why I’m strict about staying in HTTPS land when I’m on public Wi‑Fi. The EFF’s HTTPS resources explain why encrypted web traffic matters and what it protects.
Red Flags I Watch for on Airport and Hotel Wi‑Fi
I don’t assume every portal is evil.
Here are the signs that make me pause.
The Network Name Is “Close Enough” to Be Dangerous
If there are multiple similar SSIDs, I slow down. In hotels, I also ask the front desk to confirm the exact network name and whether there’s a password.
If the staff member says, “It’s the one with a lock icon,” but I only see open networks, that’s a clue that something’s off.
The Portal Asks for a Personal Email Password
A real captive portal might ask for your name, room number, last name, or a simple access code.
A portal that asks you to log in with a Google, Microsoft, or Apple ID, or your work SSO, should set off alarms. Hotels and airports don’t need your identity provider password to give you Wi‑Fi.
Certificate Warnings and “Advanced” Buttons
If your phone or laptop throws a certificate warning when the portal loads, I treat that as a stop sign. Certificate warnings can happen for a few reasons, but on public Wi‑Fi, they’re often your only obvious clue that someone is intercepting the connection.
A Download Prompt Before You’re Online
“Install this app to connect” or “download this profile” is a hard no for me, unless I’m on a corporate-managed device and IT explicitly told me to do it.
Attackers love using the portal moment to push malware, fake VPN apps, or shady “security” tools.
The Wi‑Fi Keeps Dropping and Reconnecting
Frequent disconnects can be normal in crowded places, but it can also happen when an attacker is trying to kick devices off the real network so they reconnect to the stronger fake one.
If my device keeps bouncing, I switch to cellular or my hotspot.
My Safer Routine for Using Hotel and Airport Wi‑Fi
I’m not trying to live off-grid. I just want fewer bad surprises.
Here’s the routine I use when I have to be on public Wi‑Fi:
Turn off auto-join for public networks and “forget” the old hotel Wi‑Fi after checkout. Auto-join is convenient, and attackers count on that convenience.
Confirm the exact network name with signage or staff, not a random pop-up.
Connect, finish the portal, then start my VPN (if I’m using one). Some VPNs block the portal from loading until you authenticate.
Avoid logging into sensitive accounts if I can wait, especially banking. If I can’t wait, I use cellular.
Watch the address bar once I’m browsing. I want HTTPS, and I don’t want weird redirects.
If you want official, practical advice from a government security agency, the UK NCSC has a clear guide on using public Wi‑Fi safely.
Extra Things I Do for Family Devices and Work Laptops
Public Wi‑Fi gets riskier when you’re not the only one clicking.
For kids’ tablets and phones, I keep it simple:
I disable auto-join for unknown networks.
I tell them one rule: “If it asks for an email password, stop and call me.”
For work laptops, I assume the stakes are higher. If I’m traveling for business, I prefer a hotspot. If I must use hotel Wi‑Fi, I keep my VPN on, and I avoid accessing admin panels or sensitive systems unless I’m on a trusted connection.
What I Do If I Think I Hit a Fake Captive Portal
If I connect and something feels off, I’ll do the following:
Disconnect from Wi‑Fi and turn it off for a minute.
Forget the network, so my device doesn’t rejoin.
Change any passwords I typed into that portal, starting with email accounts.
Enable multi-factor authentication if it isn’t already on.
Check for “new sign-in” alerts in your email account security page.
If you want a straightforward, consumer-friendly walkthrough on account protection and safer connections, the FTC’s security articles are a good place to start, including guidance at https://consumer.ftc.gov/topics/online-security.
Conclusion
Captive portals are normal, but captive portal attacks blend into that normal so well that people miss the warning signs. When I’m in an airport or hotel, I slow down at the exact moment most people rush, choosing the network carefully and treating portal pages like a trust test. If a portal asks for more than it should, or my device throws a certificate warning, I’m out. The goal isn’t to be paranoid; it’s to keep travel Wi‑Fi from turning into a clean-up project later.
My rule: treat OpenClaw like shadow AI that can touch real systems in your home network, because it can. Testing safely beats being fearless.
Photo by 
