SECURE PLATFORM ARCHITECTURE

Private access without opening your network.

DC Core separates public ingress, platform control and customer-side systems. Approved agents connect outwards, giving authorised users a controlled path to managed infrastructure without directly publishing internal management services.

LAYERED BY DESIGN

How a connection reaches a private service.

Each layer has a defined role. Public endpoints handle secured ingress, the control plane makes identity and routing decisions, and approved agents provide the connection point inside the managed environment.

  1. 01 / REQUEST

    Authorised user or service

    A browser, API client or approved platform service starts an authenticated request.

  2. 02 / INGRESS

    Secured public ingress

    Receives authorised HTTPS traffic and routes it towards the appropriate platform environment.

  3. 03 / CONTROL

    DC Core control plane

    Applies authentication, authorisation, tenancy, device ownership and routing controls.

  4. 04 / RELAY

    L0 or L1 mesh path

    Brokers a service path or assists an end-to-end encrypted endpoint session.

  5. 05 / AGENT

    Private workload

    The approved customer agent connects outwards and reaches the intended service or device.

RELAY & MESH

The right confidentiality boundary for each connection.

“Encrypted” can mean different things. DC Core distinguishes the two modes so buyers can understand where a connection terminates and what the relay is able to process.

L0 / HTTPS TO MESH

Controlled access to a private service

Secured public ingress receives HTTPS traffic and the platform routes it through the mesh to the approved customer-side agent or service. This supports private service publishing, monitoring and operational support without directly exposing the underlying compute resource.

  • TLS-protected public access path
  • Platform authentication, ownership and routing controls
  • Useful for authorised web and service access
L1 / E2EE MESH

Endpoint-to-endpoint encrypted access

Traffic is encrypted between the communicating endpoints. The relay may help with discovery, session establishment or path negotiation, but is not intended to inspect the encrypted payload. This mode is used when a stronger confidentiality boundary is required.

  • User-to-device, device-to-device or service-to-service
  • Designed for privileged or sensitive management actions
  • Relay assists connectivity without processing payload contents
LAYER 2 FABRICL0 and L1 provide service and endpoint paths. When distributed local networks need shared Ethernet, see the centrally authorised, encrypted Ethernet Fabric.

CONTROL PLANE

One place to govern access and operations.

The control plane provides the central application logic for identity, tenancy, device management, monitoring and operational control. Components are not treated as implicitly trusted simply because they sit inside the platform.

01 / IDENTITY

Authentication & access

WebAuthn/passkeys support high-trust flows, with multi-factor authentication where applicable and role-based boundaries for users, tenants, devices and privileged actions.

02 / DEVICES

Agent lifecycle

The platform controls agent registration, device ownership, approved configuration and the authorisation of commands sent to managed environments.

03 / KEYS

Customer-owned key access

Protected owner keys are held within a virtual keychain model. WebAuthn-backed authentication protects access to key-controlled operations.

04 / VISIBILITY

Monitoring & telemetry

Health, availability, response performance and infrastructure indicators support fault detection, troubleshooting and capacity planning.

05 / AUDIT

Event integrity

Security and operational events are recorded where appropriate, with hash-chain and immutable storage controls used to reduce the risk of audit-log tampering or destruction.

06 / RECOVERY

Resilience controls

Relay pools, multi-node services, replication, process supervision and automated recovery are applied where supported by each managed deployment.

DEPLOYMENT BOUNDARIES

Managed, customer-hosted and transitional environments.

The same platform can support directly managed workloads and existing infrastructure, but the assurance boundary changes with operational ownership.

DC CORE-MANAGED

Hosted workload architecture

DC Core provides the surrounding infrastructure, network controls, monitoring, connectivity and operational management. The customer still owns application behaviour, business data and user permissions unless a separate managed agreement covers those layers.

  • Managed infrastructure hardening and patching
  • Platform backup and recovery controls
  • Monitoring of services under DC Core control
CUSTOMER / THIRD-PARTY HOSTED

Existing and phased deployments

DC Core can provide agents, connectivity, monitoring or managed components around an existing environment. Host patching, physical controls, hypervisor security or workload backup may remain with the customer or current provider until migration is complete.

  • Clear component-by-component ownership
  • Support for phased migration
  • Assurance limited to what DC Core operates
SCOPESecurity and availability statements apply to platform services and infrastructure directly managed by DC Core. Customer applications, third-party hosting and systems outside DC Core operational control remain subject to the agreed shared-responsibility model.

PROVE THE CONNECTION PATH

Start with one bounded environment.

Share the service, device estate or hosted workload you need to manage. We’ll map the access path, ownership boundary and a practical pilot scope.

Request a technical pilot