How to Set Up Secure Remote Access to Business Applications, Step by Step

To set up secure remote access to business applications for your staff, work in six steps: list your applications and who uses them, add one sign-in with multi-factor, check device health, write an access policy for each application, pilot with one group, then move the rest and retire network-wide VPN access.

This guide is about reaching business applications from outside the office, the goal of secure remote access to business applications. Remote desktop on one PC is out of scope here. If you are still deciding on an approach, start with two decision tables and ten questions to put to a supplier. What zero trust network access means is simple: each person gets access to one application at a time, after identity and device checks.

How to Set Up Secure Remote Access: The Six Steps at a Glance

Build from the list of applications outward, and finish only when the network-wide path is closed. Also, each step produces one thing an owner can show. A list of controls gives no order, and this guide gives one.

The table lists the finished output of each step and the role that owns it. Match each role to a person in your firm before you begin. The order is practical advice from project work, with no measured results behind it.

Step 1: List Your Applications and Who Uses Each One

Write one row for each business application. Then record its owner, its users, where it runs and how staff reach it today. Include applications that a team bought on a card, and ones that staff reach only through the VPN. If the sheet misses an application, that application keeps its old path after the move.

Record which groups need which application. Then access can follow a person’s job and leave their place on the network out of it. This is also the moment to review who has access and remove people who no longer need it. Fewer users means fewer sign-ins to move and fewer accounts to defend.

Ask each application owner to confirm their row, because a sheet kept by IT alone drifts from what teams really use, and the drift shows up later as an application nobody planned for.

The output is one sheet, and every later step uses it.

Step 2: Set Up One Sign-In With Multi-Factor

Put every application behind one identity source, and also ask for a second factor at each sign-in. This is how to make remote access secure at the front door. A second factor can lower the damage when a password is stolen, because the password alone no longer opens the application. The shared tools and policies for this live in identity and access management.

Decide what the second factor can be. For example, a phone-based option needs a fallback for a lost or broken phone. Name one person who approves a reset. Then write down how they confirm that the caller is the real employee. Also test the fallback before you need it.

Connect applications in the order of the Step 1 sheet. Do not connect them all at once, because each one needs a short test with its owner.

The output is one sign-in, with a tested fallback.

Step 3: Add Device Health Checks

Decide what a device must show before it reaches an application. A short standard can be enough. Items a firm commonly includes are a supported system version, a screen lock, disk encryption and a managed or registered status. Write your own on one page.

Then define what happens when a check fails. First, the person sees a plain message that says what to fix. Second, they reach a limited set of applications, or none, until it is fixed. Finally, they have a route to fix it, such as a named contact.

Personal and unmanaged devices need their own treatment. For example, options a firm can consider include a separate work space on the device and browser-only access with no files saved to the device. Then pick one for each group of users and write it down.

The output is a short written device standard and a defined failed-check result.

Step 4: Write an Access Policy for Each Application

For each application, state who may use it, from which devices, from where and at what times. Give that person reach to the application only. The network behind it stays out of reach. This is the step that handles lateral reach after sign-in. Access to each resource is decided on identity and device before a session to it starts, not on network location alone, which is the principle in NIST’s zero trust architecture guidance.

Start from the Step 1 sheet, and give each application owner a one-page policy to approve. Do not copy one policy across applications, because sensitive applications get stricter rules, such as tighter device checks or a narrower group of users. Also set a date to review privileges, so access does not pile up as people change roles.

Keep the policies in one register, held by the IT lead. Also, when a policy changes, the application owner approves the change and the register records the date.

The output is one approved policy per application, with an owner.

Step 5: Run a Pilot With One Application Group

Pick one low-stakes group of applications and one team. Switch them to the new path, and keep the old path open beside it. That way the team has a way back while you learn.

Next, record four things: sign-in failures, failed device checks, help-desk requests and what the team says about speed. Also watch the sign-in logs, including VPN sign-ins, for spikes in failed attempts. A spike on the old path can be a signal worth acting on.

Set the widening rule before you start. For example, the pilot team signs off and the open issues are closed. Then the go decision rests on a rule agreed in advance. Then the pilot runs until the group reports no blocked work and your checks hold. The team sets that period, and it differs for each group.

The output is a pilot report and a go decision.

Step 6: Move the Rest and Retire Network-Wide VPN Access

Move the remaining groups in stages. Then close the network-wide path last, once the final application has moved and its policy works. Our article on the risks of network-wide VPN access explains why closing that path is worth the effort. Remove broad network rules in steps, application by application, and watch the logs between each one.

Keep a written way back for each move. Then, if a group is unable to work after a change, the owner knows which rule to restore and who decides.

While any VPN runs, keep it patched on the supplier’s schedule. In our view, contractors and vendors should get the same per-application policy as staff.

Name an owner for the logs and for exceptions, because an exception with no owner can stay open long after the need has passed. Also give each one an end date. Once the move is done, you can test the result with a scored review of the finished set-up, with evidence for each check.

The output is network-wide VPN access closed, and an owner for the logs.

Five Mistakes to Avoid During the Move

These five mistakes slow or undo the move. An earlier step fixes each one.

If the move stalls, go back to the Step 1 sheet. A missing row there can be the cause of later surprises.

Signisys works with firms on identity and access projects, and we deliver this work through our security services for identity and access. Start with the sheet from Step 1.

How to Set Up Secure Remote Access FAQ: Questions Before You Start