Zero Trust Architecture

What this covers

Zero Trust is a design principle: never assume a user or device is trustworthy because of where it sits on the network. For agencies with remote staff, field devices, and cloud applications, it is the practical replacement for the old perimeter model.

Typical activities

• Current-state review of identity, devices, networks, applications, and data
• Roadmap aligned to a recognized maturity model
• Strong identity with multi-factor and conditional access
• Device health checks as a condition of access
• Network micro-segmentation and private application access replacing broad VPN
• Continuous logging and analytics

What you receive

A Zero Trust roadmap with phased projects, implemented controls for each phase, and metrics that show progress.

Considerations for public agencies

Zero Trust is a program, not a purchase. We sequence it so that early phases deliver visible risk reduction, such as multi-factor authentication everywhere, before the more complex segmentation work.

Signals that the identity pillar is the place to start

Zero Trust programs usually begin because something concrete is failing, not because of a maturity score. Common triggers:

• Remote users connect through one tunnel that, once established, can reach far more systems than the few they actually use.
• Contractor and seasonal accounts stay enabled past their end dates because nothing carries a separation or contract end into the identity system.
• Multi-factor authentication covers email but not the remote desktop gateway, the firewall console, or administrative accounts in finance and permitting systems.
• A workstation at a branch facility has an open network path to a records management server or a utility control network.
• No one can say how many privileged accounts exist or which applications enforce MFA without collecting the answer by hand.

These are identity and segmentation gaps rather than tooling gaps, and they show which pillar to open first, without waiting for a budget cycle that funds the whole program.

Fitting Zero Trust to the tools and vendors you already have

Much of the first phase is configuration of products the agency already pays for. What limits it:

Identity entitlement. Policy-based conditional access, device compliance, and single sign-on often sit in a paid tier of a productivity or government agreement the agency already holds. Confirm what the current entitlement covers before anyone quotes a platform.

Endpoint tooling. Existing endpoint protection and device management usually become the device health signal. The question is whether the identity service can consume that signal, not whether to replace the agent.

Line-of-business vendors. These set the real limit. Computer-aided dispatch, records management, utility billing, and permitting systems vary widely in whether they support SAML or OIDC, allow MFA on administrative accounts, and permit service account credential rotation. Ask each vendor those questions in writing; the answers set the sequence more than any architecture decision does.

Operational technology is a separate case. Water, wastewater, and traffic systems often cannot accept agents or modern authentication, so they are handled through segmentation and brokered, monitored access instead. Where a county or state provides shared network or identity services to smaller entities, some policy decisions sit outside the agency's authority and belong in the interlocal agreement.

What to specify in a Zero Trust solicitation

• Name the maturity model to be measured against and require respondents to state a current and target stage for each pillar, rather than naming a product.
• Make an application and identity inventory a deliverable that precedes design, listing each application's authentication method, local account count, and business owner.
• Require that access policy live in an identity service the agency administers and can export, not only in a vendor console the agency loses at contract end.
• Require disclosure of the licensing the design assumes, including identity tier, private application access, and device compliance, separating what the agency owns from new purchases.
• Require pilot cohorts, a written rollback procedure for every access policy and segmentation change, and a documented break-glass account process with alerting when it is used. Locking administrators out of the identity console is a real failure mode in this work.
• If assessment and implementation are a single award, ask how the respondent handles recommending identity or private access platforms it resells.

What to measure once policies are live

Report counts rather than adjectives, on the same schedule as other operational metrics:

• Accounts using app-based or phishing-resistant authentication, tracked separately for privileged accounts.
• Applications authenticating through the identity provider, against those still holding standalone local accounts.
• Accounts with standing administrative rights, and how many have moved to time-limited elevation.
• Elapsed time from a separation or contract end to account disablement.
• Users who still require full-network remote access rather than per-application access.
• Legacy authentication protocol use in identity logs, which should trend toward zero and then be blocked.

Reassess against the same maturity model on a fixed interval, using the same scoring method, so movement is comparable between reviews. Publish the exception register alongside it: which systems hold an exception, on what basis, and when it expires.

Working with HQT on this

HQT scopes this kind of work as a fixed-price or time-and-materials engagement with a written statement of work, named staff, and a defined acceptance process. We are candid about what we can take on and prefer a well-run project to an oversized one. Contact us to discuss a requirement, a draft scope, or an upcoming solicitation.

Frequently asked questions