Case Study: Building a Practical Privileged Access Tier Model

Problem

A large New Zealand manufacturing enterprise had broad use of highly privileged accounts across the environment. Domain Admin-level access was being used for more than the most sensitive identity systems.

A large New Zealand manufacturing enterprise had a common but serious identity security problem: privileged access had expanded over time.

That created unnecessary risk. If a highly privileged account was used on lower-tier servers or shared administration paths, credential exposure could lead back to the core identity platform.

Context

The organisation needed a model that worked in the real operating environment. It was not enough to say that Tier 0 and Tier 1 should be separated. Engineers still needed to support servers, applications, patching, and platform services without breaking day-to-day operations.

The highest-risk systems included domain controllers, federation services, certificate authority components, and core directory infrastructure. Lower-tier work included regular servers, web apps, application VMs, patching, and operational support.

The issue was not that the teams were careless. They had operational responsibilities and needed to manage systems quickly. The problem was that Domain Administrator access had become the default answer for too many activities.

The organisation also relied on shared administrative access patterns, including use of a common jump box for operational administration. This created additional concern because credentials, scripts, cached sessions, and administrative artefacts could potentially be exposed in one shared location.

What was accomplished

Our team reviewed the existing administrative model, privileged groups, server roles, operational access patterns, and how engineers actually performed support.

The key finding was that many users did not need Domain Administrator access for most of their daily work. They needed reliable administrative access to the systems they supported, but not full control over the identity plane.

Key decisions and trade-offs

The main trade-off was security purity versus operational reality. A model that engineers could not use would fail. A model that allowed broad shared access would leave the main risk in place.

The practical answer was to create clear separation for Tier 0 systems while keeping support workflows usable for regular server and application operations.

Result

The organisation gained a clearer privileged access model that reduced the chance of Tier 0 credential exposure through lower-tier systems.

The review identified thousands of potential credential exposure paths, including risks from shared administration approaches. The resulting model gave the organisation a defensible way to separate identity infrastructure from day-to-day operational access.

The work was later recognised through external review and the approach was repeated across other organisations.

Conclusion

Privileged access tiering is not a diagram exercise. It has to change where accounts are used and how support work is done.

Many organisations still carry legacy administrative models where Domain Admin access has grown over time. This often happens for understandable reasons: operational pressure, urgent troubleshooting, historical access requests, or lack of a practical alternative.

A practical security and identity review can reduce privileged access risk without pretending enterprise operations are simple.