Remote work moved the security boundary into kitchens, home networks and personal browsers, and attackers followed: some of the best-known breaches of recent years began with a home computer, a synced personal browser profile or a VPN account nobody remembered. This list ranks the ten remote work security risks that most often lead to compromise, with the incident that shows each one, what to monitor and how to fix it. It draws on NIST SP 800-46 Rev. 2, the US government's guide to telework, remote access and bring your own device (BYOD) security, and on NCSC guidance. It is written for security and IT teams that support hybrid and remote staff, and for leaders deciding where to spend. The programme view is in the Home Office and Remote Worker Security Guide and the employer and employee checklists in the Remote Work Security Checklist; this page is the short list of what goes wrong.
The Top 10 at a glance
| # | Risk | What it leads to | Primary control |
|---|---|---|---|
| 1 | Phishing, vishing and MFA fatigue aimed at remote staff | Valid sessions handed to attackers | Phishing-resistant MFA, verified help desk process |
| 2 | Password-only and forgotten remote access accounts | Direct entry with a leaked password | MFA on every remote path, account lifecycle |
| 3 | Unpatched VPN and remote access gateways | Exploitation of the front door itself | Patch SLA tied to KEV, gateway hardening |
| 4 | Personal and home computers used for work | Malware on a device you cannot see or manage | Tiered access by device trust |
| 5 | Work credentials in personal accounts and browser sync | Corporate passwords stolen from outside your estate | Managed browser profiles, sync controls |
| 6 | Untrusted home and public networks | Interception and attacks from neighbouring devices | Encrypted, mutually authenticated connections |
| 7 | Exposed remote desktop and unsanctioned remote tools | Brute force, exploitation and hidden access channels | Broker access, block unapproved tools |
| 8 | Lost or stolen devices without encryption | Data and cached credentials in a stranger's hands | Full disk encryption, remote wipe |
| 9 | Shadow IT and unsanctioned file sharing and AI tools | Company data in services nobody governs | Usable sanctioned tools, discovery, DLP |
| 10 | Insecure online meetings and screen sharing | Uninvited attendees, leaked recordings | Meeting access controls, recording governance |
The ranking is our editorial judgement of how directly each risk leads to compromise. Items 1 to 3 are how attackers get in; items 4 to 7 are about the devices, accounts and networks outside your control; items 8 to 10 are about data leaving.
1. Phishing, vishing and MFA fatigue aimed at remote staff
The risk: remote staff cannot walk over to check a request, so phone calls posing as IT, repeated MFA push prompts and fake sign-in pages work better against them (MITRE ATT&CK T1566.004 Spearphishing Voice, T1621 Multi-Factor Authentication Request Generation).
Real example: in the Cisco breach of 2022, an attacker with a valid password made repeated voice calls posing as trusted organisations and sent repeated push notifications until the employee accepted one, then enrolled new MFA devices of their own.
What to monitor: bursts of denied MFA prompts, new MFA device registrations shortly after a sign-in from a new location, and help desk password or MFA reset requests for privileged users.
How to fix: move remote access to phishing-resistant MFA (FIDO2 security keys or passkeys), and at minimum number matching for push. Require identity verification before any help desk reset and alert on MFA device enrolment. See the MFA Fatigue and Bypass Guide and the Account Recovery and Help Desk Security Guide.
2. Password-only and forgotten remote access accounts
The risk: VPN profiles, legacy remote access portals and contractor accounts that accept a password alone, and accounts that stay enabled after the person or project has gone (ATT&CK T1133 External Remote Services, T1078 Valid Accounts).
Real example: in the Colonial Pipeline ransomware attack, attackers used a legacy VPN profile that was no longer in use but had never been disabled. It did not require MFA and its password had appeared in a leaked batch online. Password complexity did not help once it had leaked.
What to monitor: remote access sign-ins without an MFA claim, sign-ins to accounts with no activity in the previous 90 days, and remote access accounts with no matching active HR or contract record.
How to fix: NIST SP 800-46 recommends strong, preferably multi-factor, authentication for enterprise access from outside. Enforce it on every remote path, including the old ones, reconcile remote access accounts against HR and supplier records monthly, and disable on leaving rather than on request.
3. Unpatched VPN and remote access gateways
The risk: VPN concentrators, SSL VPN portals and remote access appliances sit on the internet by design. When a flaw is published, they are mass-scanned within days (ATT&CK T1190 Exploit Public-Facing Application).
Real example: CISA's Known Exploited Vulnerabilities catalogue lists CVE-2023-46805 (authentication bypass) and CVE-2024-21887 (command injection) in Ivanti Connect Secure and Policy Secure, remote access gateways that were exploited in the wild. See the VPN Security Guide.
What to monitor: vendor advisories and KEV additions for every remote access product you run, integrity check results, new administrator accounts and configuration changes on the appliance, and unusual outbound connections from it.
How to fix: NIST SP 800-46 recommends keeping remote access servers fully patched, managing them only from trusted hosts by authorised administrators and placing them at the perimeter as a single policy enforcement point. Set a short patch window for KEV-listed gateway flaws, keep management interfaces off the internet, and plan for a gateway you can rebuild quickly. Where you can, reduce dependence on a single network-level VPN; see the Secure Remote Access Beyond VPN Guide.
4. Personal and home computers used for work
The risk: staff sign in to corporate services from family computers and personal laptops that run unpatched software, have no endpoint protection and are invisible to the security team.
Real example: in the LastPass breach of 2022, an attacker exploited a flaw in media server software on a senior DevOps engineer's home computer (CVE-2020-5741 in Plex Media Server, fixed in 2020 and now in CISA's KEV catalogue), installed a keylogger and captured the master password to a vault holding AWS keys and backup decryption keys.
What to monitor: sign-ins from devices that are not registered or compliant, and access to privileged systems from anything other than managed devices.
How to fix: NIST SP 800-46 advises assuming client devices will become infected and using tiered access: organisation-owned PCs get broad access, BYOD and third-party devices get limited access, and personal phones and tablets get only low-risk resources such as webmail. Use conditional access that checks device compliance, offer virtual desktops or browser-only access for unmanaged devices, and allow privileged and production access only from managed, hardened devices. The NCSC notes that if users accept full management of a personal device, it should be treated as corporately issued. See the BYOD Policy Template.
5. Work credentials in personal accounts and browser sync
The risk: employees save corporate passwords in a browser signed in to a personal account, which then syncs them to every personal device that account touches. Compromise of the personal account, outside your monitoring, yields working corporate credentials.
Real examples: in the Cisco breach above, the employee's corporate credentials had been saved in the browser and synced to a personal Google account that the attacker took over. In the Okta support system breach of 2023, credentials for a service account with access to customer support cases had been saved in Chrome under an employee's personal Google profile on a company laptop.
What to monitor: browser management reports for personal profile sign-in and password sync on managed devices, and dark web or infostealer log alerts for your domains.
How to fix: manage browsers centrally: block or restrict personal profile sign-in and password sync on corporate devices, provide a sanctioned password manager, and never store service account or shared credentials in a person's browser; put them in a secrets vault. See the Browser Security Hardening Guide and the Infostealer Logs Monitoring and Response Guide.
6. Untrusted home and public networks
The risk: home routers with default admin passwords and old firmware, shared flat networks full of smart devices, and public Wi-Fi in cafes and hotels (ATT&CK T1557 Adversary-in-the-Middle).
Why it matters: NIST SP 800-46 tells organisations to assume external environments are hostile and that traffic on them can be intercepted or altered. You cannot secure every home network, so do not depend on any of them.
What to monitor: TLS certificate errors reported by managed clients, VPN or secure access client disconnections, and device posture failures such as host firewall off.
How to fix: use encryption with mutual endpoint authentication for all corporate traffic, as NIST recommends, enable host firewalls with a stricter profile on public networks, and give staff simple home router guidance (change the admin password, update firmware, use WPA3 or WPA2 with AES, turn off WPS). Replace routers the manufacturer no longer supports. See Securing Your Home Router Guide and the End-of-Life Home Routers Guide.
7. Exposed remote desktop and unsanctioned remote tools
The risk: RDP published to the internet so staff can reach their office PCs, and remote support or screen sharing tools installed by staff or suppliers without approval (ATT&CK T1021.001 Remote Desktop Protocol, T1219 Remote Access Tools).
Why it matters: NIST SP 800-46 says remote desktop access, where each internal workstation must be hardened, should only be used for exceptional cases after careful risk analysis. Unapproved remote tools give attackers a ready-made, legitimate-looking control channel, which is why help desk impersonation scams so often end with the victim installing one.
What to monitor: external scans of your address space for 3389, installations and network connections of remote access tools that are not on the approved list, and remote tool sessions outside business hours.
How to fix: remove direct RDP from the internet and broker any remaining desktop access through a gateway with MFA. Choose one approved remote support tool, block the rest by application control and network policy, and require staff to start support sessions themselves. See the Remote Desktop (RDP) Security Guide.
8. Lost or stolen devices without encryption
The risk: laptops and phones left on trains, taken from cars or stolen in burglaries, with local files, cached email and saved sessions (ATT&CK T1025 Data from Removable Media covers the related removable media case).
Why it matters: NIST SP 800-46 recommends mitigating device loss or theft with storage encryption, encryption of sensitive data or not storing sensitive data on the device at all.
What to monitor: the percentage of managed devices reporting full disk encryption on, devices not checked in for 30 days, and time from a loss report to session revocation.
How to fix: enforce full disk encryption (BitLocker, FileVault, LUKS) with recovery keys escrowed centrally, automatic screen lock, remote wipe through device management, and a simple, blame-free way to report a lost device that triggers session and token revocation. See the Disk Encryption Guide: BitLocker and FileVault.
9. Shadow IT and unsanctioned file sharing and AI tools
The risk: when the sanctioned tools are slow or blocked, remote staff email files to personal addresses, use personal cloud storage, or paste company data into consumer AI tools (ATT&CK T1567.002 Exfiltration to Cloud Storage, where the intent is malicious).
Why it matters: the NCSC warns that a BYOD scheme that makes work harder may be rejected by staff or push them towards shadow IT, which increases risk. The same is true of any remote working control that gets in the way.
What to monitor: SaaS discovery from proxy or browser telemetry, uploads to unsanctioned storage and AI services, and email forwarding to personal domains.
How to fix: provide sanctioned file sharing, collaboration and AI tools that work well from home first, then apply data loss prevention to the remaining risky paths. Explain why, rather than only blocking. See the Top 10 Shadow AI Risks.
10. Insecure online meetings and screen sharing
The risk: meeting links posted publicly, anyone able to join without a passcode, recordings and transcripts stored where everyone can read them, and screens shared with confidential content in view.
Why it matters: uninvited attendees can listen to sensitive discussions, and recordings, chat logs and AI-generated transcripts become a data store that nobody governs.
What to monitor: meetings joined by unauthenticated external participants, externally shared recordings, and new AI meeting assistant apps connected to calendars.
How to fix: the NCSC recommends securing the meeting service's admin account with a strong password, 2-step verification or passkeys and updates; admitting only authenticated users and invited guests, with passcodes for others and a waiting room; never posting links publicly; knowing where recordings, transcripts, chat logs and shared files are stored; and understanding what AI attendees collect. Set retention for recordings and tell staff to share a window rather than the whole screen. See Remote Working Security for Staff Guide.
Detection and measurement
| Signal | Source | Risks |
|---|---|---|
| Denied MFA prompt bursts; new MFA method registered after a new-location sign-in | Identity provider logs | 1 |
| Remote access sign-in without MFA; sign-in to a dormant account | VPN and identity provider logs | 2 |
| Gateway integrity check failures; new admin accounts on the appliance | Appliance logs and vendor tools | 3 |
| Access from unregistered or non-compliant devices | Conditional access and device management | 4, 8 |
| Personal profile sync on managed browsers; domain credentials in infostealer feeds | Browser management, threat intelligence | 5 |
| Unapproved remote access tool installs or connections | EDR and network telemetry | 7 |
| Uploads to unsanctioned storage or AI services; external recording shares | Proxy, CASB or SaaS audit logs | 9, 10 |
Track five measures: percentage of remote access protected by phishing-resistant MFA; remote access accounts with no matching active owner (target zero); days from KEV listing to patch for remote access gateways; percentage of corporate access from compliant managed devices; and managed devices with disk encryption on (target 100 percent).
Common failure patterns
- MFA on the main VPN, not the old one: the legacy portal or the contractor profile kept password-only access, and that is the one attackers find.
- Trusting a managed device with an unmanaged browser: the laptop is compliant, but corporate passwords sync to a personal account through the browser.
- Treating home workers like office workers: controls that assume a corporate network, such as perimeter web filtering, do nothing at home.
- Patching the gateway on the normal monthly cycle: internet-facing remote access flaws are exploited faster than that.
- Security that makes remote work harder: staff route around it with personal tools, and the risk moves somewhere you cannot see.
- No easy way to report: staff delay reporting a lost laptop or a suspicious call because they fear blame, and sessions stay live.
Mapping to ATT&CK and NIST
| Risk | MITRE ATT&CK | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|---|
| 1. Phishing and MFA fatigue | T1566.004, T1621 | IA-2, AT-2 | PR.AA-03, PR.AT-01 |
| 2. Password-only accounts | T1133, T1078 | AC-17, AC-2 | PR.AA-03 |
| 3. Unpatched gateways | T1190 | SI-2, AC-17 | PR.PS-02 |
| 4. Personal devices | T1078 | AC-19, AC-20 | PR.AA-03 |
| 5. Personal accounts and sync | T1078 | AC-20, IA-5 | PR.AA-01 |
| 6. Untrusted networks | T1557 | SC-8, AC-17 | PR.DS-02, PR.IR-01 |
| 7. Remote desktop and tools | T1021.001, T1219 | AC-17, CM-7 | PR.IR-01 |
| 8. Lost devices | T1025 | SC-28, AC-19 | PR.DS-01 |
| 9. Shadow IT | T1567.002 | AC-20, CM-10 | PR.DS-01 |
| 10. Online meetings | T1213 | AC-3, SC-15 | PR.DS-01 |
Where to start
- Week one: list every remote access path (VPNs, portals, RDP gateways, remote support tools, SaaS), the authentication each accepts and the patch level of each gateway.
- Week one: disable remote access accounts with no current owner and enforce MFA on every path that lacks it (item 2); patch any KEV-listed gateway flaw (item 3).
- Weeks two to four: turn on alerts for MFA fatigue and new MFA device registration, tighten help desk verification, and start rolling out phishing-resistant MFA to administrators and remote access users (item 1).
- Month two: apply conditional access by device compliance, block personal browser sync on managed devices, and confirm disk encryption across the fleet (items 4, 5, 8).
- Month three: remove internet-facing RDP, standardise on one approved remote support tool, set meeting and recording defaults, and review sanctioned tooling against shadow IT findings (items 7, 9, 10).
- Test and roll back: pilot each access policy in report-only mode with one team, measure help desk tickets for two weeks, then widen. Keep a documented break-glass route so a failed policy does not lock out the whole remote workforce.
Small organisations can cover most of this with the identity provider, device management and browser settings they already license. Larger ones should fold it into a zero trust access programme so that access depends on the user and the device, not the network they are on.
Practitioner checklist
- Every remote access path requires MFA; administrators and remote access users on phishing-resistant MFA.
- Help desk verifies identity before password or MFA resets; new MFA enrolments alert.
- Remote access accounts reconciled monthly against HR and supplier records.
- Remote access gateways patched within a short window for KEV-listed flaws; management interfaces not exposed.
- Access tiered by device trust; privileged access only from managed devices.
- Personal profile sign-in and password sync controlled on managed browsers; no shared or service credentials in browsers.
- Corporate traffic encrypted and mutually authenticated; staff given home router guidance.
- No RDP exposed to the internet; one approved remote support tool, others blocked.
- Full disk encryption, screen lock and remote wipe on all managed devices; lost device reporting is fast and blame-free.
- Meeting defaults restrict unauthenticated joiners; recordings and transcripts have owners and retention.
Standards and references
- NIST: SP 800-46 Rev. 2 Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security
- NCSC: Home working and video conferencing guidance
- NCSC: Bring your own device (BYOD) guidance
- CISA: Known Exploited Vulnerabilities Catalog
- MITRE ATT&CK: T1133 External Remote Services
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Home Office and Remote Worker Security Guide · Remote Work Security Checklist · Secure Remote Access Beyond VPN Guide · Top 10 Endpoint Security Risks · Top 10 Social Engineering Attacks