How do you protect critical apps when staff work remotely?

To protect critical applications when staff work remotely, stop relying on network location as proof of trust. Authenticate the user and check the device for every session, grant access to the specific application and not the whole network, put the application behind a gateway, and log each access. NIST's zero trust architecture describes this model.

Why does remote work change the risk?

When everyone sat in the office, an application on the internal network was shielded by the building and a firewall. Remote work breaks that picture. People connect from homes, hotels and personal devices, and many applications now sit in cloud services outside the company network at all.

NIST SP 800-207 addresses this directly. It describes zero trust as a response to enterprise trends including remote users, bring your own device and cloud-based assets not located within an enterprise-owned network boundary. It says zero trust assumes there is no implicit trust granted to assets or accounts based only on physical or network location or on asset ownership, and that authentication and authorization of both subject and device are discrete functions performed before a session to an enterprise resource is established.

What does that mean for one application?

Take an expense system. The old model: connect to the VPN, and the whole internal network, including the expense system, becomes reachable. The zero trust model: ask to use the expense system, prove who you are with MFA, show your device meets policy, and receive access to that application only, for that session.

NIST notes that zero trust focuses on protecting resources, such as assets, services, workflows and accounts, not network segments, because network location is no longer seen as the prime component of a resource's security posture.

How does this connect to existing remote access guidance?

NIST SP 800-46 Revision 2 on telework, remote access and BYOD security says all components of remote access technology, including organization-issued and personally owned devices, should be secured against threats found through threat modeling. CISA's ransomware guidance adds specifics: patch VPNs and network infrastructure devices, apply MFA on VPN connections, audit for systems using RDP and close unused ports, enforce lockouts, and log RDP login attempts.

Together they describe a layered approach. Keep the access path patched and hardened, and reduce what it grants once it is used.

What controls matter most for the application itself?

• Identity: MFA for every user, stronger methods for administrators.
• Device: a check that the device is managed or meets a minimum standard before allowing access to sensitive actions.
• Authorization: roles that match job duties, reviewed regularly.
• Exposure: publish the application through a gateway or proxy, so it is not directly reachable from the internet and so one choke point can enforce checks.
• Session: limited lifetime and re-authentication for sensitive actions such as changing payment details.
• Logging: record sign-ins, data exports and administrative changes, and send them to a place the application's admins cannot edit.
• Application security: remote access does not fix a vulnerable app. Keep its dependencies patched and test it against OWASP ASVS.

What can go wrong?

Constructed example. A payroll application is reachable on the internal network, and the VPN grants everyone full network access. A contractor's laptop is infected, and the malware uses the contractor's VPN session to scan the network and find the payroll server, which accepts any logged-in employee account. With per-application access, MFA and a device check, the contractor would never have seen the payroll server, and a scan from the infected laptop would find nothing to connect to.

How to check or apply this

1. List your critical applications, and note how each is reached today: VPN, direct internet, gateway.
2. Require MFA for each, and review administrator access first.
3. Replace broad network access with per-application access where the tools allow it.
4. Put internet-facing applications behind a gateway that enforces authentication, rate limits and logging.
5. Add device checks for the most sensitive actions.
6. Patch VPN and gateway software on a fixed schedule, and close unused remote desktop exposure.
7. Log and alert on new locations, repeated failures and bulk exports.
8. Test: from an unmanaged laptop, confirm you cannot reach the critical application.

Quick check

Sources

• NIST SP 800-207, Zero Trust Architecture
• NIST SP 800-46 Rev. 2, Guide to Enterprise Telework, Remote Access, and BYOD Security
• CISA #StopRansomware Guide
• OWASP Application Security Verification Standard

Last reviewed: 18 October 2026.