The Employee Laptop: An Overlooked Gateway for Hackers into Production Systems

Consider a hypothetical situation. An engineer receives a call from someone claiming to be IT support. The caller knows the company’s name and mentions an urgent security update. The engineer allows a remote support session.

The laptop already has an authenticated connection to a critical system. Depending on the permissions and controls in place, the attacker may be able to use that connection. There may be no new password prompt.

A malicious download can create a similar exposure. Malware that steals information may collect passwords, authentication tokens or other credentials stored on the device.

The risk depends on what the compromised device can reach. A laptop used only for email presents a different exposure from one used to administer several customer environments.

PwC’s 2025 Global Digital Trust Insights surveyed 4,042 business and technology executives across 77 countries and territories. It found that 77% expected their cyber budgets to increase. Yet only 2% said their organisations had implemented cyber resilience across the organisation. PwC research

These figures describe broad organisational readiness. They do not measure breaches caused by employee laptops. They do, however, illustrate the gap between funding security and applying it consistently.

That gap deserves attention wherever employees have privileged access. A well-protected server can still be exposed through an inadequately protected administrator account or device.

AnyDesk, TeamViewer, UltraViewer and Microsoft Quick Assist have legitimate uses. They help support teams investigate problems and assist remote employees.

Risk arises when the person requesting access has not been verified. Unapproved installations and unnecessary unattended access create further exposure.

Microsoft documented a relevant case in March 2026. Its incident response team had been called in during November 2025. Attackers impersonated IT support through Microsoft Teams. After two failed attempts, they persuaded a third employee to grant access through Quick Assist.

The attack then involved a fake credential form and malicious downloads. Further tooling enabled credential harvesting and session hijacking. Microsoft reported that it contained the intrusion and that the attacker’s objectives were not met. Microsoft investigation

The entry point was a support interaction that appeared credible. Organisations should make it easy for employees to verify such requests through a known internal channel.

The February 2025 Bybit attack provides another relevant example.

Safe’s published preliminary findings identified a compromised Safe{Wallet} developer machine. This enabled the proposal of a disguised malicious transaction targeting Bybit. The statement said the forensic review had not identified vulnerabilities in the Safe smart contracts or the source code of its frontend and services. Safe Ecosystem Foundation statement

For software engineering companies, this is an uncomfortable but necessary consideration. A developer’s device may have access that affects a client’s operations. Reviewing application code alone will not cover that exposure.

The World Economic Forum’s Global Cybersecurity Outlook 2026, produced with Accenture, puts supplier risk in a broader context. 65% of large companies by revenue identified third-party and supply chain vulnerabilities as their greatest challenge to cyber resilience, up from 54% in 2025. This is a survey finding about perceived challenges, rather than a count of breaches. WEF and Accenture research

Some exposures are easy to overlook because they make daily work convenient.

Passwords in text files. A note containing database credentials becomes valuable if someone gains access to the device. The same concern applies to credentials copied into chats, screenshots or shared documents.

Long-lived access keys. A production key saved for a one-time task may remain usable long after the task ends. Access should expire when the need ends.

Shared administrator accounts. Shared credentials make individual access harder to revoke. They also weaken accountability when investigating changes.

Permanent production privileges. Someone who occasionally checks logs may not need continuous permission to change infrastructure or export customer data.

Uncontrolled software installation. Browser extensions, utilities and development dependencies expand what runs on a laptop. Approval and review should reflect the access that device holds.

These practices need practical alternatives. If obtaining approved access takes hours, teams will look for shortcuts during an incident.

Multi-factor authentication remains essential. Phishing-resistant options, such as appropriately deployed security keys and passkeys, provide stronger protection against credential phishing.

But authentication does not establish that a device will remain trustworthy throughout a session. An attacker controlling a laptop may attempt to use an already authenticated session. Some attacks also target session tokens.

Passwordless authentication should not be confused with unrestricted automatic access. A hardware-backed passkey can be secure. A reusable production credential stored on a laptop presents a different risk.

Production access controls should consider the user, the device, the requested action and the duration of access. A VPN connection alone does not answer all four questions.

Start with the devices used for privileged work. Require managed laptops with current patches and endpoint detection and response. Monitor security health and restrict access when a device fails required checks. Disk encryption helps protect a lost laptop, but does not stop an attacker operating inside an unlocked session.

Control remote support tools centrally. Maintain an approved list. Disable unnecessary unattended access. Log support sessions and give employees a reliable way to verify the person requesting control.

Move passwords into an approved password manager. Store application secrets in a secrets management system. Prefer short-lived credentials where supported. Rotate credentials that may have been exposed, then remove insecure copies.

Separate everyday work from privileged administration. Use named administrator accounts with limited permissions. For sensitive environments, consider dedicated administrative devices or controlled virtual workspaces.

Make production access temporary wherever practical. An engineer investigating an issue can receive the required permissions for a defined period. Access should then expire automatically. Emergency access also needs an owner, logging and review.

Monitor what happens after login. Look for unexpected remote support activity, unusual data exports, new access keys and changes to security settings. Collect logs centrally so a compromised laptop cannot erase the only record.

Apply the same controls to vendors and contractors. Separate client credentials and access paths. Remove access when assignments end, even if the person continues working elsewhere in the organisation.

Treat the incident as a potential access breach. The response should cover every system the device could reach.

1. Isolate the device using the approved incident response process.
2. Revoke affected sessions and temporarily restrict relevant accounts.
3. Rotate exposed passwords, keys and tokens from a trusted device.
4. Preserve evidence and review activity in connected systems.
5. Coordinate with affected clients and internal owners as the scope becomes clear.
6. Restore the device and access only after the response team has validated recovery.

A password reset alone may leave other credentials or sessions usable. Response procedures should account for both.

There is no need to begin with a large security transformation programme. Begin with a clear picture of existing access.

• Who can access production, including vendors and contractors?
• Which laptops can they use, and are those devices managed?
• Which remote support tools are installed or running?
• Where are production passwords, keys and tokens stored?
• Which permissions remain active outside an approved task?
• Can the team revoke access quickly and investigate its use?

Assign an owner to each unanswered question. Then test the response with a simple exercise: assume an administrator’s laptop has been taken over.

Work through what the attacker could access, what would stop them and who would notice. The gaps will be more useful than another general reminder to be careful online.

Production security includes every person, device and credential that can reach it.