Compromised VPN credentials were the initial access vector in 48% of ransomware attacks in Q3 2025, up from 38% in Q2. That single statistic should reframe how every security leader thinks about their remote work policy this year. The remote workforce is no longer a special case bolted onto a 2020-era telework document — it is the production environment, and the policy governing it is the operating system for how identity, devices, data, and third parties interact.
Most remote work policies still in active use were drafted under pandemic pressure, refreshed lightly in 2022, and have drifted ever since. They name VPNs that are now the primary exploitation vector. They reference BYOD postures that predate the explosion of unmanaged AI tools. They assume identity lifecycle controls that don’t exist. A 2026 refresh has to do four things at once: align with current NIST and CISA guidance, reflect what attackers are actually doing, address generative AI in the workflow, and survive contact with the people who have to follow it.
What Changed Between Your Last Policy and 2026
The threat model shifted in ways your existing policy probably doesn’t reflect.
Edge devices became the primary breach vector. The 2025 wave of VPN and gateway exploits — most prominently CVE-2025-0282 in Ivanti Connect Secure — established a pattern researchers had been tracking for years. Attackers exploited a zero-day in Ivanti’s Connect Secure VPN to bypass authentication and gain deep access into enterprise networks, with financial institutions and government agencies among the hardest hit. Across 2024–2025 incidents, the dominant flow was unauthenticated exploits hitting internet-facing appliances — VPN, firewall, remote management, RMM — followed by pivots into identity providers and cloud management APIs. The attack surface your policy worries about is no longer the laptop on the kitchen table. It is the appliance terminating that laptop’s tunnel.
Identity is doing more work than the policy says it is. Most remote work policies treat MFA as a checkbox under “authentication.” In practice, identity is the entire control plane — the place where device posture, location, behavior, session risk, and entitlement all converge into a yes-or-no decision. MFA fatigue and adversary-in-the-middle phishing now bypass traditional MFA, requiring additional contextual and behavioral controls. A policy that says “enforce MFA” without specifying phishing-resistant factors is a policy that’s already behind.
Generative AI is now a data exfiltration channel. Employees paste customer records, source code, contract drafts, and internal financials into public chat interfaces dozens of times a day. In 2026, shadow-tool risk includes unauthorized use of public AI interfaces for internal business material — restricted customer, financial, legal, and operational data may not be submitted to unapproved external AI tools or unmanaged productivity platforms. If your remote work policy is silent on AI tool usage, your DLP program has a hole the size of a clipboard.
Third parties are inside the perimeter that no longer exists. Contractors, MSPs, and partner organizations log in from the same coffee shops your employees do, often with weaker controls. The breaches of 2025 made this concrete. Many large outages in 2025 traced to supplier compromise, not a single remote worker mistake.
Anchor the Refresh in NIST SP 800-46r2 and CISA Telework Essentials
Start by re-grounding the policy in primary-source guidance instead of vendor whitepapers. NIST SP 800-46r2 defines telework and remote access security as a full-system responsibility, not a single control domain — organizations should secure all components of telework and remote-access solutions, including organization-issued and BYOD devices, against expected threats. Pair it with the CISA Telework Essentials Toolkit, which separates responsibilities for executive leaders, IT staff, and end users. Then add the controls catalog from NIST SP 800-53 Rev. 5 for any control statements you make about access enforcement, audit logging, and incident response.
Mapping matters. A defensible policy ties each control statement to a recognized framework — AC-17 for remote access, IA-2 for identification and authentication, SC-8 for transmission confidentiality, SI-4 for monitoring. Auditors expect this. Internal stakeholders argue less when controls aren’t your opinion.
Identity: Make MFA Mean Phishing-Resistant by Default
Every refresh should rewrite the authentication section from scratch. The 2020-era language — “users must enroll in multi-factor authentication for VPN access” — is now actively misleading because it implies any second factor is sufficient. It isn’t.
The 2026 baseline is phishing-resistant authentication for any access that touches sensitive systems. In practice that means FIDO2/WebAuthn passkeys, hardware security keys, or platform authenticators bound to managed devices. Push notifications and SMS codes remain acceptable only as fallbacks, never as primaries for privileged access. The policy should name this explicitly.
Beyond the factor itself, the policy must cover conditional access — the rules that decide whether a successful authentication actually grants access. Zero Trust requires each session, request, or transaction to be verified against predefined policies, with techniques such as device health checks and adaptive authentication enforcing this principle. Concrete policy language: sessions from unmanaged devices get read-only access to non-sensitive resources; impossible-travel events trigger step-up authentication; sessions with risk scores above a threshold are terminated.
Standing privileges are the silent failure mode. In Zero Trust architecture, PAM enforces the principle of least privilege, ensuring that no user or system has more access than necessary and eliminates standing privileges that can be silently exploited if an endpoint gets compromised. The policy should mandate just-in-time elevation for any administrative operation, with session recording for high-risk actions, and a maximum standing-privilege count tracked as a security KPI.
Devices: Endpoint Posture Becomes a Gating Condition
The old BYOD posture — “personal devices may be used with company approval” — leaves too much undefined. A 2026 policy specifies what posture a device must demonstrate before it can reach what category of data, and what enforcement mechanism verifies that posture.
For corporate-owned devices, the baseline is full disk encryption, current OS patch level, EDR agent reporting healthy, screen lock under five minutes, and enrollment in a unified endpoint management platform. For BYOD, the policy should offer two paths: enrolled and managed (full MDM, with the same posture requirements as corporate devices, in exchange for broader access) or unmanaged with isolation (access only through a containerized environment, browser isolation, or VDI session with no local data persistence). Rather than enforcing full-device management, which raises privacy concerns and reduces adoption, companies can use containerized apps or virtual mobile environments that isolate work data from the rest of the device.
The pivotal policy decision is whether unmanaged devices can ever access regulated data. The defensible answer for most organizations in 2026 is no — not even read-only, not even briefly. Cite this in the policy. Make the exception process explicit and rare.
Network Access: Move Off VPN as the Default
The single most overdue change in most policies is the assumption that all remote access flows through a VPN. 72% of organizations maintain between two and five different VPN services, leading to fragmentation, high IT overhead, and an increased attack surface, with 67% operating at least three VPN gateways globally. Each gateway is an internet-facing appliance, each appliance is a CVE waiting to happen, and each tunnel grants more network reach than the user’s task actually needs.
The 2026 default is Zero Trust Network Access (ZTNA) for application access, with VPN reserved for narrow legacy cases (lab environments, specific protocols, OT/ICS networks) and treated as deprecated. By implementing ZTNA, organizations replace VPNs with application-level gateways that restrict access based on user identity, device health, location, and behavioral context, ensuring only compliant users and devices can access specific applications without exposing the broader network.
The policy should name the migration target — every remote-accessible application gets ZTNA-fronted by a defined date, and the VPN service is decommissioned for that application class on the same date. Without a target date, the migration won’t happen. Without a sunset for the VPN, the surface area never shrinks.
For applications that genuinely need IP-layer access, the policy must address VPN hardening: phishing-resistant MFA at the tunnel, certificate-based device authentication, microsegmentation inside the tunnel destination, and a 24-hour patch SLA on the gateway itself. Treat the VPN appliance like a domain controller, because that is what attackers treat it as.
Generative AI: The Section Most Policies Don’t Have Yet
This is the section to write before a board member asks why you don’t have it. The policy needs to address three distinct AI use cases:
Sanctioned enterprise AI. Tools the organization has procured under enterprise agreements with data processing terms, retention controls, and tenant isolation. The policy lists which tools, who can use them, and what data classes they’re authorized for. Approved use cases get explicit examples — drafting non-sensitive documents, summarizing meeting notes that don’t contain PII, writing code for non-regulated systems.
Public AI interfaces. Free or consumer-tier services where prompts can become training data. The policy should prohibit submitting any non-public business data to these services, with named examples of what counts: customer records, employee data, financial figures, source code, contracts, internal strategy documents, security configurations. Vague prohibitions don’t survive contact with a deadline.
AI-assisted code and content. Generated output is not automatically safe. The policy should require human review for code committed to production repositories, citation tracking for AI-assisted content that ships externally, and a license-conflict check for any code suggestion incorporated into proprietary software.
Enforcement requires more than policy text. DLP rules that detect data destined for known AI endpoints, secure web gateway categories that block unsanctioned services from managed devices, and browser-level controls that warn users before submission are all part of making the policy operational.
Third-Party and Contractor Access
Treat every external identity as a potential breach path until the controls prove otherwise. The policy should require:
A separate identity provider trust or federated tenant for contractors, never shared accounts. Time-bound entitlements that expire automatically — typical maximums of 30, 60, or 90 days depending on engagement type, with renewal requiring explicit re-justification. Session recording for any access to production or regulated systems. Off-boarding tied to HR or procurement events, not manual ticketing — when the engagement ends, access ends within hours, not weeks.
The policy should also require security baselines from the third party itself: attested MFA, attested EDR, attested patch posture, and contractual right to audit. Vendors who can’t attest don’t get access. This sounds harsh until you remember that many large outages in 2025 traced to supplier compromise, not a single remote worker mistake.
Logging, Detection, and Incident Response for Distributed Teams
Remote work multiplies the log sources that have to be correlated to detect a real incident. The policy should specify what gets logged, where logs are aggregated, and how long they’re retained — typical baselines are identity provider sign-ins for 12+ months, EDR telemetry for 90 days hot and 12 months cold, and ZTNA/SWG flow logs for 6 months.
More importantly, the policy should specify detection coverage requirements mapped to MITRE ATT&CK. At minimum: T1078 (Valid Accounts), T1133 (External Remote Services), T1199 (Trusted Relationship), T1566 (Phishing), T1539 (Steal Web Session Cookie), and T1110 (Brute Force). If the SOC can’t demonstrate detection logic for these against the remote access stack, the policy has a gap that the policy itself should call out.
Incident response runbooks need a remote-work variant. An incident response plan tailored for remote work scenarios is critical to responding swiftly and effectively to breaches, phishing, ransomware, and other cybersecurity incidents. Specific scenarios to runbook: stolen device with cached credentials, suspected MFA bypass, identity provider compromise, VPN gateway zero-day under active exploitation, and contractor account anomaly.
Pitfalls That Sink the Refresh
Three recurring failure modes derail policy refreshes regardless of the technical content.
Writing for compliance, enforcing for nothing. Policies that say “must” without naming an owner, an enforcement mechanism, and a metric become shelfware. Every control statement needs three companions: who is accountable, how compliance is measured, and what happens when it’s not met.
Refreshing the document without refreshing the architecture. A policy that mandates ZTNA when the organization runs three different VPNs and no ZTNA platform is a fiction. Either the architecture changes or the policy lies.
Treating the policy as a security artifact instead of a workforce artifact. Security that blocks productivity does not survive — productivity that ignores security does not last. The remote work policy is read, in some form, by everyone in the organization. If it reads like it was written for auditors, it will be ignored by everyone else.
Frequently Asked Questions
Do we need to keep our VPN at all in 2026? For most workloads, no — ZTNA is the better fit. Keep VPN for legacy protocols, OT/ICS networks, lab environments, or specific compliance regimes that require IP-layer access. Treat what remains as deprecated infrastructure with a sunset date.
What’s the minimum acceptable MFA for remote access this year? Phishing-resistant factors (FIDO2/WebAuthn, hardware keys, platform authenticators bound to managed devices) for any access to sensitive systems or privileged operations. Push-based MFA remains acceptable for low-risk applications, but plan to phase it out for everything that matters.
How do we address employee use of public AI tools without creating a black market? Provide a sanctioned alternative first. Most public AI usage is driven by genuine productivity needs that an enterprise tier can satisfy with better data terms. Then enforce the prohibition on public services through DLP and SWG, with browser-level warnings before hard blocks. People route around bans they perceive as arbitrary; they comply with rules that come with a working alternative.
Should the policy cover home networks? Yes, but lightly. Require WPA3 where the router supports it, automatic firmware updates, separation of work devices from IoT on a guest SSID where possible. Don’t try to mandate router models or run home network audits — the return on policy text spent there is low compared to endpoint and identity controls.
The Through-Line
A 2026 remote work security policy refresh is less about adding controls than about consolidating the right ones around the actual control plane: identity, device posture, and the application-level access decisions that flow from them. The VPN-era policy assumed the network was the perimeter. The 2026 policy assumes there is no perimeter and that the only meaningful checkpoint is the moment a request meets a resource.
If your refresh accomplishes one thing this year, make it this: every remote access path in the organization can answer, in real time, who is asking, from what device in what state, for what resource at what risk level — and the policy that governs the answer is named, owned, and tested. Everything else is detail.
