CASE STUDY · ZERO TRUST ARCHITECTURE IMPLEMENTATION
A zero trust network rollout for a distributed workforce.
- 90%VPN retired for 90% of apps
- 30%Access-related tickets down 30%
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market company with 350 users. Name withheld under confidentiality.
Identity-based access, device checks, discovery, a pilot and a phased rollout.
We started with discovery: a full list of apps, groups and devices, and a period of observing real traffic. We then put in a single identity provider with enforced multi-factor authentication, added device checks, and placed applications behind identity-aware access. A pilot group tested the approach before each wider phase.
- 1Reliance on a VPN and a wide internal network.
- 2Once connected, any employee could reach a large part of the internal network.
- 3Contractors and staff on personal devices used the same route.
- 4The VPN was slow, and people disconnected from it and worked around it.
- 5Access requests were handled by hand, so rules had grown untidy over years.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01Monitor mode missed an old reporting application used once a month by finance
When the policy was enforced for that department, month-end reports failed and the finance team could not reach their data. We rolled the policy back for that group within the hour. We then found the application relied on a direct database connection from desktops, which discovery had not caught because it only appeared at month end.
- PROBLEM 02We added the app to the inventory, placed it behind the gateway, and extended observation windows to cover a full month before enforcing any department's policy
- PROBLEM 03A second hurdle was device checks
Some staff used older laptops that could not meet the encryption and patch requirements, and they were blocked on the first day of their phase. Rather than loosen the policy, the company arranged replacements for the worst cases, and for a few weeks we allowed limited access to low-risk apps with a clear end date. Communication mattered here: affected users were told in advance, with a date and a contact, and complaints were few.
- PROBLEM 04Communication mattered here: affected users were told in advance, with a date and a contact, and complaints were few
03 · THE PROCESS
How we ran it.
We met the head of IT every week and held a short briefing for department heads before their group moved. Each phase had an agreed rollback.
- 01Step 1
Weeks 1 to 3: discovery, app inventory and traffic observation, with a ranked list of applications.
- 02Step 2
Weeks 4 to 6: identity and MFA tightened, device checks defined and tested.
- 03Step 3
Weeks 7 to 10: pilot with the IT team and a volunteer group, using monitor-only policies first.
- 04Step 4
Weeks 11 to 24: phased rollout by department, with a help channel and a weekly review of blocked requests.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
New apps are added to the identity provider and the gateway before launch.
- NOW 02
Access is granted by role and reviewed on a schedule, and not left to accumulate.
- NOW 03
The security team looks at risky sign-ins daily.
- NOW 04
Contractors get access only to the apps they need, for the time they need.
- 90%
VPN retired for 90% of apps
- 30%
Access-related tickets down 30%
05 · WHAT WE BUILT
How it works.
- Users sign in through single sign-on with phishing-resistant options where devices supported them.
- Access decisions combine the user, group, device state and the app being requested.
- Web and internal apps sit behind an access gateway that checks every session, so applications do not need to be reachable from the wider network.
- For apps that could not be placed behind the gateway, we used tightly scoped network paths.
- Policies began in monitor mode, so we could see what would have been blocked before enforcing anything.
- Logs from the identity provider, gateway and devices flow to the client's monitoring system.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- Reliance on a VPN and a wide internal network. Once connected, any employee could reach a large part of the internal network. Contractors and staff on personal devices used the same route. The VPN was slow, and people disconnected from it and worked around it. Access requests were handled by hand, so rules had grown untidy over years. The security team could not say who had access to what, and the board had asked how far a stolen login could go.
- What did Brandsmashers build?
- Identity-based access, device checks, discovery, a pilot and a phased rollout. We started with discovery: a full list of apps, groups and devices, and a period of observing real traffic. We then put in a single identity provider with enforced multi-factor authentication, added device checks, and placed applications behind identity-aware access. A pilot group tested the approach before each wider phase.
- How was the work run?
- We met the head of IT every week and held a short briefing for department heads before their group moved. Each phase had an agreed rollback.
- What were the results?
- VPN retired for 90% of apps; access-related tickets down 30%.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
