A quick terminology correction before anything else, because it causes real confusion: the AESCSF does not have “maturity levels” in the sense people usually mean. It has two separate scales, and mixing them up produces assessments that measure the wrong thing.
- Maturity Indicator Levels run from MIL-0 to MIL-3, and they apply to each of the framework’s eleven domains independently. Your overall MIL is the lowest score across the domains.
- Security Profiles — SP-1, SP-2 and SP-3 — are groupings of practices that define a target state, assigned by criticality to the sector. Low, moderate and high, roughly.
MILs measure where you are. Security Profiles say where you are supposed to be. The Enhanced CIRMP Rules speak in Security Profiles.
What changed
Under the baseline rules, energy entities nominating the AESCSF were working towards Security Profile 1.
The Enhanced CIRMP Rules, which commenced in June 2026, uplift that. For the nine named asset classes — which include critical electricity, gas, liquid fuel, energy market operator and water assets — the target moves to Security Profile 2, with a deadline of June 2028.
Twenty-five months sounds generous. It is not, and the reason is structural.
Why SP-2 is not “SP-1 plus a bit”
Security Profiles are cumulative. SP-2 requires SP-1 to be achieved first, in full, across every domain. So the work is not “close the SP-2 items” — it is “finish SP-1 everywhere, then close the SP-2 items”.
That matters because of how the MIL scale behaves. Your overall position is set by your weakest domain, not your average. An organisation with ten strong domains and one weak one does not sit near the top. It sits at the level of the weak one.
Most entities discover this the first time they run a proper assessment. The domains that drag are consistently the same ones, and they are consistently the ones that need the longest lead time.
Where the time actually goes
Asset inventory. Everything downstream depends on knowing what you have. In an operational technology estate this is genuinely hard: equipment installed across decades, controllers with no software inventory, SCADA estates assembled by acquisition, and a real risk that scanning disrupts the process. This is the single most common reason an assessment stalls, and it cannot be compressed at the end.
Third party and supply chain. Vendors and maintenance contractors with standing remote access into control systems are in scope, and visibility here is usually worse than assumed. “The vendor manages it” describes a dependency, not a control.
Situational awareness. Knowing what normal looks like and noticing when it stops. In estates where the network was never instrumented for security monitoring, even the foundational version is a project with procurement, installation and an outage window attached.
Identity and access. Shared operator accounts, standing vendor credentials, and passwords embedded in scripts are the normal condition rather than the exception. Fixing this touches operational practice, not just configuration, which means it moves at the speed of the people doing the work.
Evidence. The practices have to be demonstrable. Not documented to policy standard — demonstrable. “We patch our systems” is a claim; being able to show which systems, on what cadence, and when it last happened is evidence. The distance between the two is where self-assessments and independent assessments diverge most sharply.
What the enhanced rules add beyond the profile
The Security Profile uplift is not the only change. The enhanced requirements also reach into specific controls: phishing-resistant multi-factor authentication, logging, network protection and segregation for critical systems, and explicit treatment of unsupported and legacy systems.
That last one deserves attention, because it is the item most likely to require capital rather than configuration. An estate running operating systems past vendor support cannot resolve that with a policy. It needs either a compensating position that is documented and defended, or a replacement plan with dates and money attached. Both take longer than twenty-five months feels like.
A sequence that works
- Fix the boundary first. Which assets are in scope, and where does the operational environment stop and the enterprise begin? An assessment with a fuzzy boundary produces a score nobody can act on.
- Do the asset inventory early, even partially. It gates too much else, and it will never be perfect. An incomplete inventory with known gaps beats deferring the assessment.
- Assess domain by domain, and do not average. The profile is the point. A single number hides exactly the information you need to plan.
- Find your weakest domains and start there. They set your position, and they usually have the longest lead times.
- Capture evidence as you go. The assessment is when you find out what you can actually demonstrate. Record it while you are looking.
The connection to the wider program
An AESCSF assessment produces most of what a risk management program needs: a current view of capability, identified weaknesses, and a basis for deciding what is reasonably practicable. Entities frequently run the two separately and reconcile afterwards, which wastes the overlap. The asset inventory, the dependency map and the third party picture serve both. Build them once.
Working towards Security Profile 2, or trying to understand a first assessment that came back worse than expected? Get in touch.