EXPLAINER

Communicating via the RLI – A Defence Supplier Guide

The Restricted LAN Interconnect (RLI) is a connectivity capability used by authorised organisations to communicate with designated MOD services where required by a programme or contract. For a supplier, being told to communicate via the RLI usually means that certain messages, documents, applications or shared workspaces must be accessed through an environment that satisfies the programme’s security and contractual requirements rather than through the organisation’s everyday corporate systems.

Turning that instruction into a working service requires more than requesting a connection. 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.

You have been told to communicate via the RLI. 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 access, that correspondence must be sent through an RLI mailbox, or that a particular portal or collaboration service is only available through the RLI. The supplier is then left to translate a short requirement into people, devices, technology, support and governance.

The RLI should be thought of as an approved means of communication rather than a collaboration platform in its own right. Depending on the programme, suppliers may be required to use the RLI to access approved services such as collaboration workspaces, applications or other programme-specific resources. The practical requirement therefore depends on what the programme expects the supplier to reach or exchange.

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 the RLI 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. There is no single RLI service or standard onboarding process 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” 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 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 “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 the RLI.	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; 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 an RLI-enabled working arrangement 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 descriptions show that RLI-accessible services can be delivered in different ways, so 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 some form of RLI connectivity does not automatically mean every customer can reach every RLI-accessible 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 distinguishes reporting routes for suppliers with and without RLI connectivity, which reinforces the need for personnel to know the correct process 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 RLI-accessible 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.

RLI access and OFFICIAL-SENSITIVE information

RLI is often discussed alongside OFFICIAL-SENSITIVE because public MOD guidance identifies transmission through an appropriately approved network, with RLI given as an example, as one condition that can support the electronic movement of such material. That does not make RLI connectivity a 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

RLI and the MOD Core Network, commonly shortened to MCN in public material, are distinct terms. Public Defence documents refer to different access routes for different user groups and services, while Government procurement records describe applications that can be reached by MOD users and approved industry partners through RLI connections.

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 the RLI can sit alongside wider contractual cyber obligations. Where DEFCON 658 is invoked, CSMv4 uses a Cyber Risk Profile and the controls in Defence Standard 05-138 Issue 4 to assess the supplier’s organisational security and resilience. The exact profile and Supplier Assurance Questionnaire are determined through the MOD process, not by the presence of RLI connectivity.

Many of the practical capabilities needed around RLI-enabled 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 RLI-accessible services the arrangement supports, 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 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 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 RLI 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 RLI-accessible 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 RLI 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.

Is RLI the same as the MOD Core Network?

No. They are distinct terms used in public Defence material. The relevant question for a supplier is which approved route provides access to the specific application, recipient or workspace required by the contract.

Does 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 RLI-enabled service does not provide blanket authority across other services or projects.

How long does it take to put an RLI-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: 13 July 2026.