You will never administer the network your team actually uses

A lean team gave up the corporate LAN a long time ago, and with it any ability to administer the network its people actually work on. The traffic now rides a home router nobody patched, a hotel access point shared with strangers, and the open Wi-Fi at a cafe where the "network" is whoever else is sitting nearby. You cannot harden those networks. You will never even see most of them.

So the strategy inverts. Instead of securing the network, you make the device safe to use on a network you assume is hostile — and then you prove every machine clears that bar. This is the practical face of zero trust: stop trusting the network entirely, and push the security onto the endpoint and the connection. The perimeter already moved into people's backpacks; remote-work security is about making that backpack safe to open anywhere.

What a hostile network can actually do

It helps to be precise about the threat, because the folklore is worse than the reality and the reality is bad enough. On a network you do not control, an attacker positioned between your user and the internet can try to:

  • Snoop unencrypted traffic. Anything not wrapped in TLS is readable. In practice most apps now use HTTPS, which is exactly why the encryption in transit story matters so much — it is what neutralizes the classic coffee-shop eavesdropper.
  • Tamper with what is not authenticated, including pushing fake captive portals and bogus update prompts that try to get a user to install something.
  • Attack the device directly if it is exposing services to the local network — a reason the endpoint baseline, specifically the host firewall, is doing quiet work every time someone opens a laptop in a shared space.

The reassuring part: modern encryption defeats most passive snooping on its own. The unglamorous part: that only holds if the device is configured correctly and stays that way, which is the whole job.

The baseline that makes a hostile network survivable

You do not need to forbid public Wi-Fi — an unenforceable rule your team will quietly ignore. You need a device baseline that makes the network's hostility irrelevant.

  • Encryption everywhere by default, with full-disk encryption for the stolen-laptop case and TLS for everything in transit. A modern browser warning on a non-HTTPS site is a feature; teach people not to click past it.
  • A host firewall on and inbound closed, so a laptop on a shared network is not quietly offering services to whoever else is on it.
  • DNS you can trust. Hostile networks love to tamper with name resolution; encrypted DNS or a managed resolver removes one of the cheaper tricks, the same DNS hygiene instinct you apply to your own domains, turned toward the client.
  • A VPN for the cases that need it, understood for what it is. A VPN protects the link to its exit point and is genuinely useful on a sketchy network — but it is not a magic shield, it does not patch the device, and it does not undo a malicious app the user already installed. Sell it as one control, not a force field.
  • Patched and auto-updating software, because a hostile network is precisely where an unpatched bug gets probed, so the patch cadence is part of the remote-work story, not separate from it.

Enforcement is the hard part, not the list

A baseline in a wiki is a wish. What makes it real for a distributed team is the ability to push the policy to every machine and read back whether each one actually complies — the same device-management discipline that keeps a fleet honest. Without that read-back you are trusting that a dozen remote people each remembered to turn on the firewall and keep updates current; with it, you have a fact instead of a hope.

That read-back is the whole point. "Is the host firewall on and the OS current, right now, on every remote laptop?" should be answerable with a number, not a survey — and the BYOD reality of a lean team, where some of those machines are personal, makes clear BYOD boundaries part of the same conversation rather than an afterthought.

A non-compliant remote device is a finding, not a footnote

When the device baseline reports a remote laptop with the firewall off, updates stale, or disk encryption disabled, that is not a someday item — it is a finding with an owner and a clock, ranked by what the machine can reach using your exposure-first triage. A developer laptop with production access on a hotel network and no encryption outranks a kiosk that browses the marketing site.

  • Route remote-device drift into the same workflow as every other risk — owner, severity, deadline — not a separate spreadsheet.
  • Watch for drift, not just initial state. A firewall gets disabled to troubleshoot a printer and never re-enabled; updates get paused before a demo and stay paused. Coverage is a continuously verified number.
  • Feed it to the audit. Every framework asks how you secure devices that access company data from outside the office; a clean device-compliance report drops straight into evidence collection.

One honest caveat: a platform can track whether your remote devices meet the baseline, surface the ones that drift, and keep that evidence current for an auditor — it organizes, watches, and proves the work. It does not secure the coffee-shop Wi-Fi, configure anyone's laptop, make you compliant, or grant or guarantee any certification; the encryption, the firewall, the VPN, and the patching are operational steps your team owns, and which obligations apply to remote work for you is a question for counsel.

You will never administer the network your team works on, so stop trying. Make the device safe to use on a network you assume is hostile — encryption on, firewall up, DNS trusted, software current — and then prove every machine clears that bar and stays there. The coffee shop is not the problem you can fix. The laptop is.