ZERO-TRUST INFRASTRUCTURE ACCESS
Give remote IT teams the access they need—not a trusted network position.
Authorise each infrastructure request using the identity, device, target, action and relevant context. Keep access narrowly scoped and observable across home offices, customer sites, data centres and cloud environments.
SHORT ANSWER
Replace “connected to the right network” with “explicitly authorised for this resource and action”.
Inventory the people, services, devices and infrastructure targets first. Establish strong identities for each, collect reliable device or service-health signals, and use policy to decide whether a specific request should proceed. Broker the smallest useful connection, protect it over every network and record enough context to investigate what happened. Zero trust is an architecture and operating discipline; buying a remote-access product does not complete it.
This approach follows the resource- and identity-led direction in the NCSC zero-trust design principles and NIST SP 800-207. DC Core applies relevant principles within its platform boundary; that does not make the customer’s entire organisation “zero trust”.
THE ACCESS DECISION
Evaluate five things before opening a session.
Remote administration has a high impact radius. Treat the permission to sign in, the permission to reach a target and the permission to perform an action as separate decisions.
Who or what is requesting access?
Use an authoritative user, service or device identity and strong authentication appropriate to the operation. Shared administrator accounts weaken both control and evidence.
- Individual or workload identity
- Role and tenant membership
Is the request credible now?
Consider relevant signals such as device status, identity lifecycle, authentication strength, request origin, service health and abnormal behaviour.
- Risk-relevant signals
- Step-up or denial when needed
What exactly can be reached?
Authorise the named service, VM, device or workload rather than granting broad network presence. Separate read, diagnostic, change and privileged functions where possible.
- Narrow target scope
- Explicit action authority
How is the connection protected?
Authenticate and encrypt across every network. Use controlled service publishing or endpoint-to-endpoint encrypted paths according to where traffic may legitimately terminate.
What proves the policy worked?
Record relevant identity, target, policy and operational events. Protect logs, monitor agent and relay health, and assign ownership for denied or unusual access.
REMOTE TEAM OPERATING MODEL
Design for real administrators and real failure modes.
The strongest policy still fails if it blocks urgent work with no controlled alternative. Build joiner, mover, leaver, emergency and supplier paths into the model.
Review the DC Core connection model →- 01
Separate workforce and privileged identity
Do not let an everyday productivity identity silently inherit universal infrastructure authority. Apply stronger authentication and narrower lifetime where the risk warrants it.
- 02
Register managed endpoints and agents
Associate devices and agents with the correct owner and tenant. Define the health information the policy can reliably use and what happens when a signal is missing.
- 03
Publish resources, not whole networks
Where practical, broker access to the required system or service. If a broader network route is genuinely necessary, segment it and keep onward reach deliberate.
- 04
Control third-party and temporary access
Give suppliers named identities, bounded targets, agreed windows and an owner. Make expiry and removal part of the workflow rather than a later clean-up task.
- 05
Prepare emergency access
Protect a fallback path for identity-provider, agent or control-plane failure. Make its use attributable, restricted, tested and reviewed after every activation.
ZERO TRUST VS REMOTE ACCESS TOOL
Capabilities matter; the surrounding process completes the control.
Use this table to spot the gap between a connection product and a working access architecture.
| Capability | Tool can help with | Organisation still must own |
|---|---|---|
| Authentication | Passkeys, MFA, service credentials and session establishment. | Authoritative identities, lifecycle, role design, recovery and acceptable authentication strength. |
| Device context | Agent identity, registration and available posture or connectivity signals. | Endpoint management, supported software, health policy and response to non-compliant devices. |
| Authorisation | User, tenant, device, target or command checks supported by the platform. | Business approval, least-privilege role definitions and periodic access review. |
| Connection | Outbound-agent paths, secured ingress, relays and endpoint encryption where supported. | Local segmentation, egress rules, application security and third-party network controls. |
| Monitoring | Platform events, agent state, service health and relevant access evidence. | Triage ownership, cross-system investigation, retention requirements and incident response. |
COMMON FAILURE MODES
Avoid zero-trust theatre.
A design can use modern identity and still reproduce the same broad, permanent trust it was meant to remove.
MFA plus an unrestricted tunnel
Strong authentication is valuable, but it does not justify giving every authenticated user broad network reach. Scope the resource and action after authentication.
A trusted managed device
Ownership or enrolment is a signal, not permanent proof of safety. Device status, identity and requested resource should still influence each decision.
One policy for every administrator
Platform, customer, supplier and support roles rarely need identical targets or commands. Design permissions around operating duties.
No fallback for control-plane failure
If urgent recovery requires bypassing the model, protect and test that path. Otherwise the first outage may create an undocumented permanent exception.
PHASED ADOPTION
Start with one team, one resource group and one policy.
Measure whether the new model reduces exposure and access breadth while preserving a usable operational path.
- 01 / INVENTORY
Map identities and targets
Record users, devices, agents, services, suppliers, current routes and privileged actions.
- 02 / POLICY
Define allowed requests
Set strong authentication, target, action, context, expiry and exception requirements.
- 03 / PILOT
Broker narrow access
Use a representative environment and test normal, denied, degraded and emergency paths.
- 04 / REVIEW
Use the evidence
Inspect policy outcomes, support friction and gaps before extending the model.
COMMON QUESTIONS
Zero-trust remote access FAQs.
Zero trust is a direction of architecture and operations, not a binary product badge.
Does zero trust mean trusting nobody?
No. It means removing implicit trust based only on network location, ownership or a previous connection. Requests are explicitly evaluated against policy using the identities and signals available for the resource.
Does zero-trust access replace a VPN?
Sometimes it can replace a broad remote-access route for specific applications or infrastructure targets. Other environments may retain VPNs for defined needs while applying stronger identity, segmentation and resource-level policy. The models are not always mutually exclusive.
Can outbound agents support zero-trust principles?
They can support a reduced-exposure, resource-specific connection model when enrolment, identity, authorisation, path protection and monitoring are designed properly. Outbound network direction alone is not zero trust.
Does DC Core certify our whole environment as zero trust?
No. DC Core can provide relevant platform controls and a managed connection path within an agreed boundary. Your identity sources, endpoints, applications, policies, user lifecycle and out-of-scope networks remain part of the organisation-wide architecture.
RELATED DECISIONS
Connect policy to the infrastructure path.
MAP THE CURRENT TRUST
Show us who can reach which systems today.
Share the remote teams, suppliers, infrastructure targets, current VPNs or public ports and the actions each role needs. We’ll map a bounded access pilot and the responsibilities outside DC Core.