EXPLAINER

Communicating via the MOD Core Network (MCN) – A Defence Supplier Guide

Editor’s note: This article was updated in August 2026 to reflect current MOD terminology. References to RLI have been updated to MOD Core Network (MCN), while legacy terminology is retained where relevant.

Current MOD contractual documentation uses MOD Core Network (MCN) for the communications infrastructure serving the Defence community and identifies Restricted LAN Interconnect (RLI), Assured LAN Interconnect (ALI) and Official LAN Interconnect (OLI) as legacy naming for MCN. Defence suppliers may nevertheless continue to encounter RLI in contracts, public guidance, service descriptions and programme conversations.

For a supplier, being told to communicate via RLI or MCN usually means that certain messages, documents, applications or shared workspaces must be reached through an approved environment rather than through the organisation’s everyday corporate systems. Turning that instruction into a working service requires more than requesting connectivity. The supplier needs to confirm the exact communication requirement, the information involved, who needs access, which devices will be used and which contractual security conditions apply. Those details determine whether an existing environment can be adapted or whether a managed, project-specific capability is needed.

What happened to RLI?

Restricted LAN Interconnect remains a familiar term across the defence supply chain and still appears in current public MOD guidance. Current MOD contractual documentation makes the relationship explicit by identifying RLI, ALI and OLI as legacy naming for the MOD Core Network (MCN).

For suppliers, MCN should therefore be treated as the current terminology while RLI is retained where it appears in contracts, guidance or existing service descriptions. The terminology alone does not define the service requirement: the programme still needs to identify which application, mailbox, workspace, recipient or workflow the supplier must reach.

You have been told to communicate via the RLI or MCN. What does that mean?

The instruction often appears during a bid, contract award or mobilisation conversation with little supporting explanation. A project lead may state that users need RLI or MCN access, that correspondence must be sent through an RLI mailbox, or that a particular portal or collaboration service is available through the Defence network. The supplier is then left to translate a short requirement into people, devices, technology, support and governance.

The key is to separate the network requirement from the service users actually need to reach. MCN provides the Defence network context; the practical requirement may be access to a collaboration workspace, application, mailbox, portal or other programme-specific resource. Current public material is not terminologically uniform, with some MOD guidance still referring to RLI, so suppliers should focus on the named service and approved working process.

For one contract, the requirement may centre on email or a shared project workspace. For another, it may involve access to a designated application, reporting portal or information repository. Knowing that MCN or RLI access is required is the start of the conversation; the named service and working process are what allow the supplier to design a usable solution.

The exact implementation will vary between programmes. Public material does not describe one universal MCN onboarding route that applies to every Defence contract, which is why clarifying the requirement early is so important.

Start by turning the acronym into a defined business requirement

Before buying equipment or selecting a provider, ask the MOD customer, prime contractor or other contracting authority to define the requirement in operational terms. The answer should identify the service or recipient involved, the types of activity users must complete and the point at which the capability is expected to be available.

It is useful to work through a representative task. For example: a named engineering team needs to receive marked documents, comment on them in a shared workspace and return an approved version to the programme. That description reveals far more than the phrase “RLI access” or “MCN access” because it identifies the people, information, applications and data movement that need to be supported.

The requirement also needs a clear owner. Suppliers should know who can confirm the approved communication route, who can answer questions about information handling, and who will accept that the delivered arrangement meets the programme need. Where the instruction has flowed down through a prime contractor, the prime should be able to connect the supplier with the relevant security and technical authorities rather than leaving the subcontractor to infer the design.

The questions to clarify with the customer or prime

A productive first discussion focuses on the work that must happen. Confirm which application, workspace, mailbox or MOD-facing service users need to reach; whether the need is one-way or two-way; and whether the requirement applies during the bid, after contract award or throughout delivery.

The information itself is equally important. Establish the expected classification and markings, the need-to-know population, any dissemination restrictions, and whether a Security Aspects Letter or other programme instruction has been issued. Do not use the presence of MCN or RLI connectivity as a substitute for those decisions. The authority that owns the information and the contractual documents define what may be handled and by whom.

Finally, establish scale and operating context. How many people need access? Where will they work? Will external consultants or subcontractors be involved? Do users need a full collaboration environment, occasional portal access or a dedicated communication channel? These answers shape the cost, delivery model and time needed to mobilise.

From contract requirement to working service

There is no useful shortcut from the words “MCN access required” or “RLI required” to a production-ready service. The work normally moves through a small number of connected decisions, each of which reduces uncertainty before users are onboarded.

Stage	What to establish	Why it matters
1. Define the interaction	Name the application, recipient, workspace or workflow that must be reached through MCN or the approved Defence route.	The connectivity design has to serve a specific task rather than an undefined network requirement.
2. Confirm the authority	Identify who owns the requirement, approves the route and answers handling questions.	Suppliers need a current source of direction when the contract wording is unclear or changes.
3. Understand the information	Confirm classification, markings, need-to-know, retention and any Security Aspects Letter conditions.	The information determines the controls and user population; MCN or RLI access alone does not decide this.
4. Select the service model	Decide whether to adapt an approved existing environment or procure a managed project service.	The choice affects delivery time, internal workload, assurance evidence and ongoing support.
5. Prepare users and devices	Create individual accounts, provide managed endpoints where required and define support and training.	A connection is only useful when authorised people can complete the real task safely and reliably.
6. Test the workflow	Run representative exchanges, access changes, support requests and incident scenarios before go-live.	Testing exposes gaps while there is still time to correct them without delaying delivery.

What a supplier will usually need in place

The exact design varies by programme, but a working arrangement that includes MCN access normally brings together several capabilities. Treating connectivity as the only deliverable leaves the supplier with an incomplete service and often pushes unresolved questions onto users during mobilisation.

An approved route to the required service

The organisation needs a service arrangement that provides the approved access required for the named MOD application, recipient or workspace. Public Defence and Government descriptions show that applications and services can be made available to authorised industry users through MCN, while older and some still-current material may describe those routes using RLI. A supplier should ask the provider to state precisely what is included, who authorises it and which user workflows it supports.

This evidence should be specific to the contract need. A provider having the ability to reach MCN does not automatically mean every customer can reach every Defence-facing service through it. The relevant route, service boundary and responsibilities need to be documented.

Individual identities and controlled access

Each user should have an individually attributable identity, suitable authentication and permissions limited to the work they need to perform. The operating model should cover account approval, creation, access reviews, role changes, leavers and the handling of privileged administration.

Shared credentials make accountability and offboarding difficult. They also weaken the organisation’s ability to establish who accessed a document or performed an administrative action. Where shared mailboxes or project groups are required, membership should still resolve to named users and be reviewed throughout the contract.

Managed endpoints

The laptop or desktop used to reach the service forms part of the communication path. It may display sensitive material, store local copies, cache credentials and connect to printers, removable media or other networks. The supplier therefore needs to know which devices are authorised and how they are configured, patched, protected and monitored.

Some services may require a dedicated managed endpoint. Others may support an approved corporate device or controlled virtual access pattern. The decision should come from the service design and contract rather than user convenience. Personal devices should not be assumed to be acceptable, and current public MOD guidance expressly restricts sending OFFICIAL-SENSITIVE information to personal devices by email.

The application or collaboration workspace

Users need an approved place to complete the work, which may include email, document management, messaging, meetings, workflow or access to a specialist application. The service should make it clear where information is stored, what can be downloaded, how external participants are invited and how access is removed when the work ends.

For ongoing collaboration, a shared workspace can reduce the uncontrolled spread of attachments. Membership and permissions can be managed centrally, while the project retains a clearer record of versions and activity. The workspace still needs to be approved for the relevant use and operated in line with the contract.

Monitoring, incident handling and support

A usable service needs people and processes behind it. Authentication, administrative changes, access events and endpoint security signals should be available for investigation, with a defined process for triage and escalation. Current MOD incident guidance still uses the legacy RLI term when distinguishing reporting routes for suppliers with and without RLI connectivity. That is a useful reminder that legacy terminology remains present in current material, and that personnel need to know the reporting process that applies to their organisation before an incident occurs.

Day-to-day support is just as important. Users need somewhere to report access failures, lost devices and suspected misdirected information. The service owner should understand who handles each issue, how quickly it is escalated and where customer or MOD responsibilities begin.

Information-handling guidance for users

Technology does not tell a user whether a particular person has a need-to-know or whether a document has been marked correctly. Users need concise instructions covering the approved account and device, the workspace or mailbox to use, recipient checks, marking, local storage, printing, onward sharing and what to do when the normal route is unavailable.

The guidance should reflect the actual contract rather than a generic security policy. If the programme changes its working process, adds a subcontractor or introduces a new information type, the instructions and permissions should be reviewed at the same time.

Can you use your existing corporate IT?

Possibly, but it should never be assumed. A supplier’s existing Microsoft 365 tenant, email service or managed laptop may provide useful controls without providing the approved route to the required MCN-connected or Defence-facing service. The customer requirement and service provider need to confirm which parts of the existing estate can remain in use and where a separate boundary is required.

Adapting an existing environment can reduce disruption if the organisation already has mature identity, endpoint management, monitoring and service operations. It can also introduce integration work and ambiguity over where project information may move. A dedicated managed environment may be faster to evidence and easier to separate from general corporate activity, particularly where only a defined group of users needs the capability.

The right decision depends on timescale, internal expertise, user numbers, the expected contract duration and the exact service required. The comparison should include ongoing operation, support, patching, monitoring, audit evidence and secure exit rather than concentrating only on initial licences and devices.

MCN, RLI and OFFICIAL-SENSITIVE information

RLI remains explicitly named in current public MOD guidance on the electronic movement of OFFICIAL-SENSITIVE information. ISN 2023/04 gives RLI as an example of an appropriately approved network that can support electronic transmission, even though newer MOD contractual documentation identifies RLI as legacy naming for MCN. The terminology overlap does not create blanket authorisation to handle every OFFICIAL-SENSITIVE document or to use every available service.

Need-to-know, marking, recipient suitability and programme-specific handling instructions continue to apply. Current MOD contractual guidance states that where pre-contract or contract aspects are graded OFFICIAL-SENSITIVE or above, the contracting authority uses a Security Aspects Letter to identify the classified aspects and the required security conditions. If the requirement is unclear or impracticable, the supplier is expected to raise the issue with the contracting authority.

Information remains subject to those controls after it reaches the supplier. Copying a file into another tenant, downloading it to an unmanaged device or forwarding it through an unapproved channel can move it outside the intended boundary. The supplier needs a documented rule for what users may do with information received through the service.

How RLI relates to the MOD Core Network

Current MOD contractual documentation makes the relationship explicit: MOD Core Network (MCN) is the current network term, while Restricted LAN Interconnect (RLI), Assured LAN Interconnect (ALI) and Official LAN Interconnect (OLI) are identified as legacy naming for MCN. That terminology has not been applied consistently across every still-current MOD document; current OFFICIAL-SENSITIVE transmission and incident-reporting guidance, for example, continues to use RLI. Suppliers may therefore encounter both terms in legitimate current and legacy material.

Suppliers do not need a map of the wider network architecture to act on a contract requirement. They need confirmation that the proposed service provides the approved route for the named users and task. A provider should be able to explain that service boundary at a useful level without relying on vague statements that it is simply “connected to Defence”.

Where CSMv4 fits

A requirement to communicate via MCN can sit alongside wider contractual cyber obligations. Where DEFCON 658 is invoked, Defence Standard 05-138 Issue 4 sets out controls applicable to CSMv4 and the relevant Cyber Risk Profile. MOD guidance issued in March 2026 confirms that a supplier holding and maintaining valid Defence Cyber Certification (DCC) at an equal or higher level may submit that certification as evidence that the corresponding Defence Standard 05-138 control requirement has been satisfied. The applicable Cyber Risk Profile and assurance activity are determined through the MOD contractual process, rather than by the presence of MCN connectivity.

Many of the practical capabilities needed around Defence-connected collaboration align with the areas covered by the Defence Standard: identity and access management, trust in devices, secure configuration, data protection, logging, monitoring, incident response and supply-chain risk. A managed service can support those controls within its boundary, while the supplier remains responsible for understanding its contract and completing the assurance required of the organisation.

Do not overlook subcontractors and temporary project users

Defence delivery often involves specialist subcontractors who join for a limited phase. If they need to communicate through the same service, the prime or contracting supplier should determine whether the requirement and associated security conditions must be flowed down, how access will be approved and whether the subcontractor will use its own controlled environment or be onboarded into another service.

Temporary access still needs a complete lifecycle. The individual should be verified, given only the workspace and information required, supported while active and removed promptly when the task ends. Project teams should not leave this until a subcontractor is waiting for documents, because rushed onboarding is where shared accounts, uncontrolled forwarding and informal workarounds tend to appear.

What can go wrong when the requirement is left too late

The most common impact is delay rather than an immediate security incident. A supplier reaches mobilisation and discovers that key staff cannot access the required portal, the proposed devices are not supported, or the service has not been approved for the intended workflow. Delivery pauses while ownership, procurement and assurance are resolved.

Workarounds create a more serious problem. Users under pressure may send material through ordinary email, place documents in a separate cloud service, share credentials or ask another organisation to act as an informal relay. Those actions can undermine need-to-know, auditability and the contractual handling model even when the underlying intent is simply to keep the programme moving.

There can also be a hidden operational burden. A solution that provides connectivity without endpoint support, monitoring or a clear service desk may leave a small supplier responsible for specialist administration it did not budget for. The gap becomes visible when a user is locked out, a laptop is lost or the customer asks for evidence of an event.

What to ask a prospective service provider

The provider should begin by understanding the named Defence workflow rather than offering a generic secure workspace. Ask which Defence-facing services the arrangement supports, whether the required MCN access is included, what customer or MOD approvals are required, and which parts of onboarding depend on third parties.

The service boundary should be explicit. Confirm whether endpoints are supplied and managed, how identities are created, which collaboration tools are included, how activity is monitored, who responds to alerts, what support hours apply and how users are removed at the end of the contract.

Evidence matters more than broad claims. A provider should be able to explain its service-management and security processes, describe the assurance that applies to the delivered service, and distinguish between controls it operates and obligations retained by the customer. It should also be willing to identify any dependency that could affect the mobilisation date.

Questions to answer before the project starts

• Which named MOD-facing service, recipient or workflow requires MCN access, or is described in the contract as requiring RLI access?
• Who owns and approves the communication requirement?
• What information will users receive, create or transmit, and which handling instructions apply?
• How many users need access, from which organisations and locations?
• Which endpoints are permitted, and who manages their security throughout the lifecycle?
• Where will project information be stored, and can it be downloaded or moved elsewhere?
• How will accounts, permissions, shared mailboxes and subcontractor access be reviewed?
• Who monitors the service and handles security alerts, incidents and lost devices?
• What support will users receive when the service is unavailable or the workflow fails?
• What needs to happen when a user, subcontractor or contract leaves the environment?

The next action after MCN or RLI appears in a bid or contract

Place the requirement on the mobilisation plan immediately and assign an owner. Ask the customer or prime to define the exact service, workflow, information and approval route, then assess users, endpoints, collaboration tools, monitoring and support as one service boundary. That early clarification gives the supplier the best chance of reaching contract start with a working, supportable route rather than an unresolved acronym and a delivery team waiting for access.

---

Frequently asked questions

Can a supplier simply apply for generic MCN access?

Public material does not describe one universal onboarding route that covers every supplier and service. The practical path depends on the programme, the MOD or prime authority, the required Defence-facing service and the organisation providing the working environment. Start by asking the party that imposed the requirement to name the service and approving contact.

Does every employee need MCN access?

Usually only the people with a defined role and need-to-know should be given access. Limiting the user population reduces cost and administration while supporting least privilege. The contract and workflow should determine which roles require the service.

Will users need a separate laptop?

That depends on the approved service design. A programme may use a dedicated managed endpoint, an approved corporate device or another controlled access model. The supplier should confirm this before ordering equipment or assuming existing devices are suitable.

How does RLI relate to the MOD Core Network?

Current MOD contractual documentation identifies Restricted LAN Interconnect (RLI), Assured LAN Interconnect (ALI) and Official LAN Interconnect (OLI) as legacy naming for the MOD Core Network (MCN). Suppliers may still encounter RLI in current guidance and older contract or service language, so the exact Defence-facing service and workflow should still be confirmed.

If my contract says RLI, is the requirement obsolete?

No. The terminology may be legacy while the underlying access requirement remains valid. Confirm which Defence service, application, recipient or workflow the contract expects you to reach, and use MCN as the current terminology when discussing the requirement unless the contracting authority directs otherwise.

Does MCN or RLI connectivity mean the organisation can handle any OFFICIAL-SENSITIVE information?

No. The service must be approved for the intended use, and the contract, Security Aspects Letter, information owner, markings and need-to-know requirements still govern the information. Access to one Defence-connected service does not provide blanket authority across other services or projects.

How long does it take to put an MCN-enabled service in place?

Timing depends on the service, sponsorship and approval dependencies, user numbers, device provisioning, configuration, onboarding and testing. Treat the requirement as an early mobilisation dependency and ask providers to identify assumptions rather than offering an unsupported fixed estimate.

What should the supplier do first?

Obtain written confirmation of the exact workflow and the authority responsible for it. Once the service, users, information and required date are clear, the supplier can assess its existing environment and seek a provider that can evidence the complete operating model rather than connectivity alone.

---

---

Important note: This guide is intended as an overview to help organisations understand the principles and practical considerations of this topic. It is not a substitute for official guidance, contractual requirements or professional advice. Always refer to the latest official guidance and the specific requirements of your organisation, customer or contract before making implementation or compliance decisions. Last reviewed: 7 August 2026.