The Health and Social Care Network (HSCN) is a network connectivity solution owned by NHS England that allows connected organisations to reach both centrally hosted NHS services and other HSCN consumers. It was designed as a replacement for the legacy N3 Network, operated by BT, and provides greater scale, security, and performance compared to its predecessor. This guide provides a technical overview of the HSCN: how it connects organisations, how its architecture works under the hood, and the considerations that matter most when consuming or providing HSCN services.
At its core, the HSCN operates similarly to the internet. HSCN consumers connect to a Consumer Network Service Provider (CN-SP), who in turn connects into the wider HSCN.
CN-SPs operate in a similar fashion to an internet service provider, with a range of accredited providers able to deploy connectivity solutions for their customers. Any organisation that needs to consume or provide NHS services can connect to the HSCN, and the process for doing so is documented in our HSCN compliance process guide.
There are multiple components that form the HSCN. Understanding what each does and how it fits into the overall solution is useful for any organisation planning a connection.
The Peering Exchange is the backbone of the HSCN, and follows a standard architecture found in internet exchanges around the world. It provides high-speed, redundant connectivity between CN-SPs and serves as a central aggregation and peering point ensuring all providers connect via a standard pattern.
The Peering Exchange comprises a geo-diverse topology deployed in both London and Manchester, with a redundant pair of network switches in each location connected via redundant, high-speed links.
All CN-SPs are obligated to physically connect to these switches in both locations, ensuring the solution is resilient against hardware failure at either site.
The Peering Exchange also provides redundant route servers that simplify and aggregate the logical peerings between all CN-SPs. They create a full mesh between all CN-SPs from a routing perspective, without the overhead of manually establishing all the individual peerings.
CN-SPs are responsible for connecting HSCN consumers to the Peering Exchange and the wider HSCN. All CN-SPs go through an extensive audit process before certification, with a set of mandatory obligations they must follow from both a technical capability and operational perspective.
Whilst each CN-SP’s architecture is unique, the diagram below shows a typical setup of a CN-SP connecting to the Peering Exchange and its customers.
Competition between CN-SPs was one of the driving forces behind the HSCN and the migration away from N3. By allowing for an open market, NHS England ensures that HSCN consumers have freedom of choice, and that all CN-SPs are obligated to provide good service at a reasonable price.
To allow for DNS resolution over the HSCN, NHS England provides a redundant DNS service that enables resolution of HSCN-only fully qualified domain names, with an upstream forwarder for internet FQDN resolution.
For organisations that do not require internal DNS resolution, they can resolve against the HSCN DNS servers directly. For those that do require internal resolution, they can use the HSCN DNS servers via a conditional forwarder or as an upstream resolver.
The most complex component of the HSCN is its routing and IP allocation methodology, and this is the most common source of confusion for new consumers.
Because the HSCN connects a wide variety of organisations – all with unique IT teams and architectures – a frequent issue is overlapping internal RFC1918 IP space between different organisations.
This is a challenge common to any shared communication network. The typical solution on the internet is to allocate each consumer a unique publicly routable IP range that cannot conflict with other organisations.
However, providing this on the HSCN would require NHS England to procure and allocate a large volume of public address space across all connected consumers. The cost would be significant and would severely limit the HSCN’s scalability.
To address this, NHS England allocates RFC1918 private IP address space to organisations as requested. Whilst technically private addresses, these are treated as “public” HSCN ranges and used to enable inter-organisation communication without the cost of public address space.
All HSCN consumers must route out to the HSCN sourced from a HSCN “public address”, and any service made available on the HSCN must be presented as such.
The HSCN carries a large number of unique IP prefixes advertised via the peering exchange. Whilst this allows flexibility for organisations to advertise their HSCN public space as needed, it creates complications from a routing perspective – both due to the volume of prefixes and the potential for overlap with an organisation’s internal routing.
To address this, many CN-SPs – including Cloud Gateway – aggregate the HSCN routing table down to a set of large, generic prefixes, which are then advertised to customers. This reduces the number of prefixes being handled and ensures that any conflicting but more specific prefixes within the HSCN consumer network always prefer the internal route.
Over the years Cloud Gateway has provided HSCN connectivity, we have supported hundreds of customers through the process of getting connected and helping them to both consume and provide HSCN services. We have identified a number of key considerations that we recommend all prospective, current, and future HSCN consumers understand.
The most distinctive aspect of the HSCN is its IP allocation model and the potential for conflicting ranges. Understanding how you will consume the service and what changes may be needed on your network is important before connectivity is provisioned. For many organisations the process is straightforward, but we have seen edge cases where a unique internal architecture has required a bespoke design.
We also strongly recommend requesting your own HSCN IP space, directly owned by your organisation. Whilst all CN-SPs hold HSCN IP space and can allocate it to customers, that space is ultimately owned by the CN-SP – meaning it cannot be easily transferred if you change provider. Many providers are happy to make these allocations precisely because it creates switching friction.
Having your own IP space removes that dependency entirely. NHS England has made requesting IP space a straightforward process, and in our experience this often takes less than 24 hours. As an HSCN customer, you should expect high-quality service from any CN-SP, and owning your IP space ensures you can migrate to a new provider whilst retaining the same range if required.
A common misconception is that because the HSCN is a private network, it should be treated as inherently secure and not subject to the same security controls as other environments. Whilst it is more secure than an untrusted network such as the internet, and NHS England has implemented a number of security controls that improve the HSCN’s overall security posture, it should still be treated as an untrusted network.
It is the responsibility of each HSCN consumer to ensure they are consuming and providing HSCN resources securely, and implementing controls that protect their environment from malicious traffic.
The 2017 WannaCry ransomware attack on the NHS illustrates why this matters. The attack infected thousands of vulnerable Windows machines across hundreds of NHS organisations. Whilst the root cause was an unpatched vulnerability in Windows, the attack used both the internet and the legacy N3 network to spread between organisations. The network perimeter alone was not sufficient protection.
We recommend adopting a zero trust approach to HSCN connectivity, with at least one – and ideally two – firewall solutions in the path between your users and the HSCN. Limit outbound access to only the services you are consuming, blocking all other outbound traffic. Where you are offering a solution that requires inbound access, permit only from trusted endpoints on required ports.
If you are transmitting sensitive data, we recommend creating a VPN tunnel over the HSCN as you would over the internet, ensuring data is encrypted in transit and cannot be intercepted.
Cloud Gateway can provide managed security as part of your HSCN service, delivering the required level of protection without the overhead of managing it independently. Speak to your CN-SP and understand their recommendations on how to securely access the HSCN.
There are around 20 accredited CN-SPs able to provide HSCN services. All must follow NHS England-defined obligations and pass regular audits to demonstrate they are doing so.
When selecting a provider, we recommend approaching multiple CN-SPs to discuss your requirements and evaluate their proposed solutions. The HSCN was designed to give customers choice, and you should use it.
When evaluating potential providers, consider support quality in an emergency and day to day, how seriously they take security as an operational priority, whether pricing is competitive relative to the market, and whether working with them has been clear, responsive, and focused on your actual requirements.
The HSCN is more complex than its documentation suggests. Success requires understanding the unique IP allocation model, implementing proper security despite the network being “private”, and choosing a CN-SP based on service quality rather than cost alone.
Our key recommendations: request your own IP space from NHS England, treat the HSCN as untrusted from a security perspective, and thoroughly test routing before moving to production. Getting these fundamentals right will save significant troubleshooting time later.
For help with specific HSCN requirements or questions about implementation, see our Business Connect: HSCN page or get in touch directly.
