DART Accreditation and What MOD Assurance Looks Like in 2026

MOD Cyber Assurance

Since the MOD moved away from its former accreditation model, “Is it MOD accredited?” has remained one of the first questions many defence suppliers ask when considering a secure collaboration environment. For years, it was a sensible shortcut. A DART reference or MOD accreditation status appeared to provide a simple answer: the system had been through a recognised Defence assurance process within a defined scope.

That shortcut no longer reflects current MOD policy. In July 2023, the Ministry of Defence stopped applying accreditation to new projects as it introduced Secure by Design. In May 2025, it formally removed the requirement for suppliers to register services processing MOD information, confirming that supplier assets do not need to be registered on CAAT, the tracker that replaced DART for MOD programmes and projects.

This was a policy-wide change, not the withdrawal of approval from a particular supplier or service. The former supplier accreditation route was retired. Buyers must now look at the current evidence that applies to the supplier, the service, the capability and the contract.

In plain English: assurance has not disappeared. The former system-level accreditation process has been replaced by a broader model built around continual risk ownership, contract-specific controls, supplier evidence and independent certification where applicable.

What was DART accreditation?

DART stood for the Defence Assurance Risk Tool. It was the MOD platform used to register and manage assurance activity for ICT systems handling MOD information. The phrase “DART accredited” became common industry shorthand, although DART was the tracking tool rather than the accreditation itself. More precisely, a defined system or service had been assessed through the MOD accreditation process, with its scope and status recorded in DART.

That distinction matters because even under the former model, accreditation was never an unlimited guarantee. It related to an agreed scope, architecture, operating model, information classification and set of assumptions at a particular point in time. Changes to the service, its use, its integrations or its threat exposure could affect the assurance position. A DART number did not mean that every deployment, user behaviour, customer process or future configuration was automatically secure.

The status nevertheless gave buyers a recognisable reference and reduced the amount of interpretation needed during early procurement conversations. Its removal has created a communication gap. Customers still want the confidence represented by the old label, while suppliers can no longer renew or obtain that label through the route MOD has ended.

Why MOD moved away from accreditation

MOD explained that cyber security was too often addressed late in a programme, with teams preparing for an accreditation event after major design decisions had already been made. The Secure by Design launch material described this as security being “bolted on” near the end of the lifecycle. The replacement approach puts accountability with Senior Responsible Owners, capability owners and delivery teams, who are expected to understand and manage cyber risk from concept through operation and disposal.

This is a shift from periodic approval towards continual assurance. Security activities, risk assessments, control decisions, testing, vulnerability management and evidence are expected to evolve with the capability. MOD’s current guidance describes Secure by Design as an approach used at every lifecycle stage and makes clear that security is an ongoing part of capability development and operation.

The change can feel less certain because it removes a single certificate-shaped answer. In exchange, it is intended to produce a more current view of risk. A service can change rapidly through software updates, new integrations, changing users and emerging threats. An accreditation decision made months or years earlier cannot, on its own, show how those changes are being controlled today.

The old shorthand and the new assurance question

AreaFormer accreditation modelCurrent assurance model
Main questionDoes the system hold MOD accreditation?How is risk being controlled, evidenced and reviewed for this capability and contract?
TimingFormal assessment and renewal pointsContinual assessment through the lifecycle and when material change occurs
Primary scopeA defined system or service boundaryCapability risk, supplier resilience, contract controls and the service boundary
EvidenceAccreditation status and supporting assurance artefactsRisk evidence, control mappings, SAQs, testing, operational records and relevant certifications
AccountabilitySupported by a central accreditation processSRO and delivery-team ownership, with independent assurance used where relevant

The assurance landscape today

A useful way to understand the current landscape is through three connected areas. This is not a formal MOD classification, but it helps separate assurance of the capability, assurance of the supplier’s contractual cyber resilience and independent certification. They overlap, but no single area is a direct replacement for former system accreditation.

1. Secure by Design: managing assurance for the capability

Secure by Design applies throughout the lifecycle of Defence capabilities, including capabilities delivered with industry partners. MOD programme and project teams use CAAT to track security activities, assess maturity and produce Statements of Assurance. Suppliers do not register capabilities on CAAT themselves; they work with the Defence contracting authority and provide information and evidence as required under the contract.

The SRO, or suitable equivalent, remains accountable for deciding whether cyber risks are understood and managed within the applicable risk appetite. CySAAS may provide independent assurance in selected cases, but MOD guidance states that assessors highlight risk rather than decide whether a capability is secure. The decision therefore rests on the body of evidence for the capability, not on a single platform certificate.

2. CSMv4 and DEFCON 658: assurance of supplier cyber resilience

The Cyber Security Model version 4 addresses cyber resilience across the Defence supply chain. A risk assessment completed by the MOD Delivery Team determines the contract’s Cyber Risk Profile, from Level 0 to Level 3. Defence Standard 05-138 Issue 4 defines the controls required at each level, and suppliers complete a Supplier Assurance Questionnaire against the assigned profile. Where applicable, the requirements are flowed down to subcontractors under DEFCON 658.

CSMv4 deliberately looks beyond a single collaboration platform. It focuses on the organisation, systems, processes and dependencies involved in delivering the contract. A managed secure collaboration environment can implement and evidence relevant technical and operational controls, but it cannot fulfil the customer’s governance, personnel, supply-chain, business continuity and risk-management responsibilities on its behalf.

3. DCC: independent assurance of organisational cyber resilience

Defence Cyber Certification provides independent, organisation-wide certification aligned to the CSMv4 control levels. In March 2026, MOD confirmed that a current DCC certificate at the appropriate level is to be accepted as assured evidence that the supplier has satisfied the corresponding Defence Standard 05-138 control requirements under DEFCON 658. A higher DCC level can also satisfy lower control levels.

DCC assesses the cyber resilience of the certified organisation. It does not provide MOD accreditation for an individual product or platform. Current MOD guidance also requires suppliers to complete the full SAQ through the Supplier Cyber Protection Service, including where they hold DCC, while recognition of certification within the online tooling continues to develop.

What should a defence buyer ask now?

An answer to “Is it MOD accredited?” may now refer to a historic system status, a current organisational certification or a service-specific assurance claim. These are not interchangeable. A more useful due-diligence conversation starts by establishing scope, currency and the evidence behind each claim.

AskWhat a useful answer should explain
What exactly is in scope?The organisation, service, tenant, endpoint, user group, data type, integrations and contract assumptions covered by each assurance claim.
Which evidence is current?Valid certificates and their scopes, control mappings, architecture documentation, test evidence, operational reports and review dates.
How does the service contribute to CSMv4 compliance?Which Defence Standard 05-138 controls are implemented or evidenced within the service, and which responsibilities remain with the customer.
How has Secure by Design informed the service?How the principles have informed its architecture, development and through-life operation, supported by evidence of risk ownership, testing, change control and clear responsibility boundaries.
How is the environment operated?Identity and access governance, endpoint control, logging, monitoring, vulnerability management, patching, incident response, backup, recovery and change management.
What happens when the service changes?How significant changes are assessed, documented, tested and communicated, and how assurance evidence is kept current.

Certifications such as DCC, Cyber Essentials Plus and ISO/IEC 27001 can strengthen that evidence within their respective scopes. ISO/IEC 20000-1 can also provide useful assurance around the management and continual improvement of a live service. None should be treated as a universal substitute for understanding the actual architecture, operating model and customer responsibilities.

What this means for DISX

DISX Secure Collaboration was designed for Defence use and assessed under the MOD accreditation process in place at the time. That provides important assurance history and context for the service. Since the MOD retired its previous accreditation model, assurance is now demonstrated differently, through the evidence, controls and responsibilities expected under the current MOD approach.

That evaluation should consider how identities and endpoints are controlled; how information is separated and protected; how activity is logged and monitored; how vulnerabilities, patches, changes and incidents are managed; how availability and recovery are governed; and how evidence is maintained and made available for assurance. DISX provides a managed technical and operational environment that aligns with the CSMv4 controls. Its architecture, development and through-life operation are informed by Secure by Design principles. These service controls form part of the customer’s wider contractual and organisational assurance position.

Logiq holds DCC Level 0, Cyber Essentials and Cyber Essentials Plus certification, together with ISO/IEC 27001, ISO/IEC 20000-1 and ISO 9001 certification. These provide independent assurance across organisational cyber resilience, baseline technical controls, information security management, service management and quality.

Taken together, this gives buyers a clearer picture than a single historic term: the supplier’s certifications, the service controls and operating evidence, and the responsibilities specific to the contract and deployment.

How Logiq can help

The move away from DART has left many organisations using assurance language that no longer matches the MOD process. Logiq can help buyers, delivery teams and suppliers translate current requirements into practical evidence: defining boundaries, mapping relevant controls, identifying gaps, preparing documentation and explaining how a managed environment contributes to the wider assurance case.

For organisations considering DISX, the most useful conversation begins with the work being delivered, the information involved, the assigned or anticipated Cyber Risk Profile, the devices and users requiring access, and any contract-specific Security Aspects Letter or connectivity requirements. This allows the assurance position to be described against the actual use case and contract.