PRIVATE NETWORKING & SECURE REMOTE ACCESS
Connect authorised users and services to private infrastructure through controlled relay paths. Customer-side agents normally connect outwards, so internal management services do not need to be directly published to the public internet.
Use one service, site or device estate as a bounded pilot.
A SMALLER PUBLIC ATTACK SURFACE
DC Core separates the public access layer, control plane, relay mesh and customer-side environment. Each layer has a defined job, and access remains subject to identity, tenancy and routing decisions.
Approved agents establish encrypted outbound communication with DC Core. That provides a controlled connection point without making every internal system independently reachable from the internet.
The control plane applies authentication, authorisation, device ownership, tenancy and command controls before an approved platform action or connection is established.
Use controlled HTTPS-to-mesh publishing for private services, or L1 end-to-end encrypted mesh connectivity where the payload must remain protected between endpoints.
TWO CONNECTION MODES
The relay is not described as “blind” in every mode. DC Core makes the connection boundary clear so technical and security teams can choose the right pattern.
Secured public ingress receives HTTPS traffic, then routes the approved connection through the mesh to the appropriate customer-side agent or service. This supports private application access, monitoring and operational workflows without exposing the underlying compute resource directly.
Traffic is encrypted between the communicating users, devices or services. The relay can assist discovery, session establishment or route negotiation, but is not intended to inspect or process the encrypted payload.
PRACTICAL USE CASES
Use the mesh to create authorised paths to systems that are difficult or undesirable to expose directly.
Discuss a connection path →Provide authorised access to an internal web application or service through secured ingress and the appropriate customer-side agent.
Reach approved devices for monitoring, diagnostics or management without placing a general-purpose inbound management interface on the public internet.
Connect remote sites, servers or network-connected systems through authenticated agents and tenant-aware platform controls.
Add secure connectivity and visibility around an existing environment while infrastructure ownership or hosting remains with the current operator.
CONNECTION DESIGN
The design starts with the target service and who should reach it. That avoids opening a broad tunnel when a narrowly controlled service path is the better answer.
Define the service, device or environment, its current network position and the users or systems that need access.
Select controlled service publishing or endpoint-to-endpoint encryption based on the required confidentiality boundary.
Install an approved agent in a controlled zone and apply the required identity, tenant and routing configuration.
Validate access behaviour, failure handling and monitoring before extending the pattern to more resources.
CONTROL PLANE SAFEGUARDS
DC Core does not treat internal components as implicitly trusted. Communication between platform services, agents and endpoints is authenticated and protected within the applicable connection model.
WebAuthn/passkeys are supported for high-trust flows, with multi-factor authentication used where applicable for administrative and sensitive platform functions.
Users receive access to the customers, devices and functions required for their role. API requests are authorised against the relevant user, tenant, device or service identity.
Agent communication, relay availability and response performance contribute to operational monitoring, fault detection and investigation within the managed platform.
SHARED RESPONSIBILITY
DC Core manages the platform components and connectivity it operates. Your local network and any infrastructure outside that managed path remain under the customer or existing provider.
| Area | DC Core | Customer |
|---|---|---|
| Relay platform | Secure operation of relay services, control-plane routing, tenant controls and managed agent connectivity. | Appropriate use of the platform and reporting suspected misuse or access concerns. |
| Local network | Agreed secure access paths and network controls inside DC Core-managed environments. | Site connectivity, local segmentation, internal firewall policy and third-party network changes outside DC Core control. |
| Endpoints | Agent registration, platform-side ownership and approved lifecycle controls. | Endpoint security, operating-system controls and applications not included in the managed service. |
| User access | Platform authentication, role-based access and privileged administrative controls. | User permissions, suitable MFA adoption and removal of access when no longer required. |
| Application traffic | Transport and relay protection for the selected DC Core mode. | Secure behaviour, data handling and encryption inside customer applications and third-party integrations. |
COMMON QUESTIONS
Every customer network is different. We use the first conversation to confirm the target, local constraints and right connection mode.
Customer-side DC Core agents normally initiate outbound connections to the platform, so inbound management firewall openings are not normally required. The final network design still depends on the service and customer environment.
No. DC Core distinguishes L0 and L1 modes. L0 receives public HTTPS at secured ingress and routes it through the mesh to a private service. L1 encrypts traffic between communicating endpoints, while the relay assists discovery or routing and is not intended to inspect the encrypted payload.
Yes. Approved agents can be deployed into customer-hosted, remote or transitional environments. Assurance applies to the DC Core components and connectivity under our control; you or your existing provider remain responsible for out-of-scope infrastructure.
Global relay locations support routing, availability and latency. They are not intended to act as primary storage for customer tenancy data, although encrypted traffic and limited service metadata may be processed as part of normal delivery.
No. It reduces unnecessary public exposure and centralises the managed connection path. Customers still need suitable endpoint security, local segmentation, application controls, user governance and secure third-party integrations.
CONNECTED SERVICES
MAP ONE CONNECTION
Tell us what needs to connect, where it runs and who needs access. We’ll map the likely L0 or L1 path and a bounded technical pilot.