Password1 on a 2012 Test Account: ICO Reprimands Data Cymru and Ogi

On 20 October 2026 the UK Information Commissioner's Office published reprimands against Data Cymru and its IT provider Ogi Networks. A ransomware attacker got in through "Test2", a test account created in January 2012 with the password "Password1". Data on 3,300 people, mostly children, was taken. Any team that shares a directory with a provider should audit stale accounts this week.

The reprimands carry no fine. What makes them worth reading is the detail. The regulator lays out, step by step, how one forgotten account with a dictionary password, a remote access group nobody pruned, and a local administrator password that never changed turned into data theft and encryption across a domain controller, a file server and a database server. It also explains why two organisations share the blame: one created the account, the other controlled the network, and the contract between them never said who was supposed to check.

This post goes through what the two reprimands say, with dates and figures taken from the documents themselves, then turns that into a practical audit you can run against your own Active Directory and remote access setup. It ends with what would have helped and where Safeguard does and does not fit.

A note on sources: both reprimands are published as scanned images. We ran optical character recognition on our copies of the two PDFs and checked every figure here against the ICO's HTML news release and against reporting from The Register, Infosecurity Magazine and Nation.Cymru.

What happened

According to the ICO, the attack against the Local Government Data Unit, Wales (known as Data Cymru) began on 1 November 2024. Data Cymru is a Welsh local government company that helps councils and other public bodies collect, analyse and present data. Ogi Networks Limited (ONL), a Cardiff network provider, had supplied Data Cymru with managed IT services since 2012, including server and connectivity infrastructure, licensing, managed backup and IT support.

The ICO says the attacker used the "Test2" account to get into Data Cymru's network, encrypted 182.7GB of data and, before encrypting anything, took 42GB from a primary domain controller, a file server and an SQL server. The ICO release says the stolen information related to two projects supporting children and families, and that personal information of 3,300 people was taken, most of them children.

Both organisations received reprimands under Article 58(2)(b) of the UK GDPR. The ICO's head of investigations, David Doodson, summed up the case in one line: "Password1 is not an appropriate password, it is a wide-open door to nefarious actors."

Timeline

All dates come from the two reprimands unless another source is named. Neither reprimand gives times of day.

Two things stand out. First, the attacker was active for about six weeks before the ransomware went off: the earliest "Test2" activity the investigators found was 20 September, and encryption came on 1 November. Second, the account clean up that would have removed "Test2" took just over four hours once both parties sat down to do it. The ICO makes that point itself, noting the audit was "neither complex nor time-consuming".

Who is affected

The Data Cymru reprimand says the South Wales Regional Organised Crime Unit (Tarian) and the National Cyber Security Centre have been monitoring the dark web, and that there is no evidence to date of the personal data being published. Neither the ICO nor Data Cymru had received complaints from data subjects at the time the reprimands were issued. The ICO does not name the ransomware group, and none of the reporting we read does either, so we do not attribute it.

How the attack worked

The reprimands describe a short chain. None of it needed a software vulnerability. Every link was an identity or credential decision made years earlier and never revisited.

1. A test account that outlived its purpose

"Test2" was created on 13 January 2012 so ONL could test user access before moving Data Cymru's real staff across. Once the migration was done, the account had no job. ONL told the ICO that "Test2" either stayed active the whole time or was inadvertently reactivated at some point before the attack. Either way, it existed in Data Cymru's directory for more than 12.5 years.

2. A password that predates the password policy

Data Cymru did have a password policy. According to its reprimand, a Group Policy Object required 15 characters and at least two of uppercase, number or non-alphabetic character, with passwords set never to expire. That sounds reasonable. The catch is how Active Directory applies password policy: it checks a password when the password is set or changed. It does not reach back and test passwords already stored.

"Test2" predated the stronger policy and, because nobody used it, never changed its password. So "Password1", which would fail the 15 character rule, sat untouched under a policy that would have rejected it on day one. The ICO notes that a third-party strength tool rates "Password1" as very weak and crackable in under a second.

ONL had its own Identity Management Policy with minimum password standards following NCSC guidance, but the reprimand records that the policy governed ONL's own accounts and was not in place when "Test2" was created.

3. Remote access for an account nobody owned

"Test2" was a basic domain user with no administrative rights, which is exactly why it looked harmless. But it was also in the SSL VPN group. The investigators reviewed VPN logs and found that initial access came through a VPN client connection under the username "Test2". The ICO says the account was likely compromised by password spraying, where an attacker tries one common password across many usernames, staying under per-account lockout limits.

When an account like this can reach the network from the internet with a single factor, its rights inside the domain matter much less than you might think. It gets the attacker a foothold on the inside of the perimeter.

4. One local administrator password on three servers

Here is where a basic user became a domain-wide problem. The investigators found that the local administrator accounts on the primary domain controller, the file server and the SQL server all used the same password. ONL confirmed it never reviewed those local administrator accounts after deploying them in January 2012, so the same default passwords were in place for more than 12.5 years.

The reprimand explains the consequence in plain terms: once one system was breached, local account hashes could be collected and used to authenticate to the others. On Windows, a local account hash can be presented for network authentication without knowing the plain text password. If every server shares that hash, compromising one server compromises them all. This is the specific problem Microsoft built Windows LAPS to remove, and Microsoft's own documentation names pass-the-hash and lateral traversal as what it protects against.

5. Exfiltration, then encryption

With access to the domain controller, file server and SQL server, the attacker took 42GB of data and then deployed ransomware. The ONL reprimand splits the 182.7GB that was encrypted into 42.7GB on a file server and 140GB on an internal SQL server.

6. The review that missed the account

Data Cymru told the ICO it did run user account reviews before the incident, but not on a schedule, and it could not say when the last one happened. More important for anyone running their own review: those reviews asked ONL for the members of the "Domain Users" group, not the full contents of Active Directory. Data Cymru later acknowledged it should have asked for everything. An account that is not where you look is an account you never review.

The post incident audit found eight deprecated accounts. Seven were standard user accounts. One belonged to a web development consultant and held administrative credentials. The account owners' roles included the chief executive and a research officer.

Technical details

There is no CVE, no malware hash and no network indicator in this case. The reprimands publish none, and the ICO does not name the ransomware family. What they do publish is a precise record of the identity configuration that failed, which is more useful to most defenders than a hash would be. Every value below comes from the reprimands as read by OCR, cross checked against the ICO release.

Accounts named in the reprimands

Systems affected

Password and policy settings

Remote access changes after the incident

• ONL modified SSL VPN access to use Microsoft Entra ID with MFA (ONL reprimand, para 42(b)).
• Data Cymru changed SSL authentication on its firewall to SAML single sign-on from Entra ID instead of the local Active Directory, enabling MFA for all SSL VPN access (Data Cymru reprimand, para 51(c)).
• Data Cymru migrated to an Entra ID environment after the incident (ONL reprimand, footnote 43).

Regulatory record

Industry guidance the ICO cited

The ICO did not invent a new standard here. Both reprimands point to guidance that was public well before the attack:

• CIS Critical Security Controls version 8, Control 5 (May 2021): keep an inventory of accounts, use unique passwords, disable dormant accounts.
• NCSC Cyber Essentials, Requirements for Infrastructure v3.1 (April 2023), requirements 2 and 4: remove or disable unnecessary accounts and change default or guessable passwords. The ONL reprimand also notes the scheme's password controls: MFA, or a minimum length of 12 characters, or a minimum of 8 characters combined with automatic blocking of common passwords through a deny list, with no maximum length.
• The joint advisory on threats to managed service providers and their customers, published 11 May 2022 by agencies including the NCSC, CISA, NSA and FBI (CISA alert AA22-131A). It tells customers and providers to find and disable accounts no longer in use, require MFA on provider accounts and spell out in the contract who owns which security tasks.
• NCSC password administration guidance for system owners (November 2018), which ONL's own policy followed.

What the reprimands do not tell us

• The ransomware family, the ransom demand, or whether one was paid.
• The VPN appliance version, or whether it had any unpatched flaw. The investigators attribute access to the "Test2" credentials, not to a VPN vulnerability.
• How the attacker moved from a basic user to the first server. The reprimand describes hash reuse between servers once one was breached, not how the first one fell.
• The data fields in the stolen project data, and the names of the two projects.
• Why "Test2" was enabled in 2024: the reprimand records ONL's answer as either always active or inadvertently reactivated.

Why the controller and the processor were both reprimanded

The most transferable lesson is not about passwords. It is about how an outsourced directory falls between two organisations.

The reprimands describe a split that will be familiar to anyone who uses a managed service provider. Data Cymru kept overall control of its network. ONL could only create and remove accounts on Data Cymru's instructions, which came from Data Cymru's head of ICT through ONL's helpdesk. Documented "New Users" and "Leavers" processes covered joiners and leavers. Nobody's process covered accounts that were neither: test accounts the provider created for its own project work.

The ONL reprimand calls this "a gap in the account auditing process between both organisations". ONL would not remove an account without an instruction. Data Cymru would not instruct removal of an account it did not know about. "Test2" lived in the gap for over a decade.

The contract made the gap worse. The only agreement Data Cymru could produce was a 2016 Order Form for "Managed Hosted IT Services, AD Rights Management". The Data Cymru reprimand records that it said nothing about how the Active Directory service would be delivered, monitored or audited, and contained none of the data protection terms Article 28(3) requires. Data Cymru told the ICO it reviewed its contracts before GDPR came into force but overlooked this one, partly because it saw ONL as an infrastructure provider rather than a sub-processor. The ICO found that the missing terms contributed directly to the incident, because nobody had defined who monitored and audited the directory.

That is why Data Cymru's reprimand includes Article 28(4), which requires a processor that engages a sub-processor to pass on the same data protection obligations by contract. ONL's reprimand stays with Article 32, the security of processing duty that applies to processors and sub-processors directly.

If you run IT through a provider, or you are the provider, three questions follow from this:

1. Who is contractually responsible for reviewing every account in the directory, not just joiners and leavers?
2. Who removes accounts the provider creates for its own work, such as test, migration, service and break glass accounts?
3. How often does that review happen, and who signs off that it did?

If you cannot answer all three from the contract, you have the same gap.

What to do now

The steps below are what the reprimands point to, turned into commands. They are written for an on premises Active Directory with remote access, which is the setup in this case. Run them from a management workstation with the RSAT Active Directory module, using an account with read access to the directory. Read only queries come first; nothing changes until step 6.

1. Export the whole directory, not one group

Data Cymru's earlier reviews only looked at "Domain Users". Start with everything.

Import-Module ActiveDirectory

Get-ADUser -Filter * -Properties Enabled, whenCreated, LastLogonDate, PasswordLastSet,
  PasswordNeverExpires, PasswordNotRequired, Description, MemberOf, AdminCount |
  Select-Object SamAccountName, Name, Enabled, whenCreated, LastLogonDate, PasswordLastSet,
    PasswordNeverExpires, PasswordNotRequired, AdminCount, Description,
    @{n='Groups';e={($_.MemberOf | ForEach-Object { ($_ -split ',')[0] -replace '^CN=' }) -join ';'}} |
  Export-Csv .\ad-users-full.csv -NoTypeInformation

Do the same for computers and groups so you can see stale machine accounts and nested group paths:

Get-ADComputer -Filter * -Properties Enabled, LastLogonDate, OperatingSystem, whenCreated |
  Export-Csv .\ad-computers-full.csv -NoTypeInformation

Get-ADGroup -Filter * -Properties Members, whenCreated, Description |
  Select-Object Name, GroupScope, whenCreated, Description, @{n='MemberCount';e={$_.Members.Count}} |
  Export-Csv .\ad-groups.csv -NoTypeInformation

2. Find enabled accounts nobody uses

Search-ADAccount -AccountInactive returns accounts that have not logged on within a time span. Filter to enabled users:

Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly |
  Where-Object { $_.Enabled } |
  Select-Object SamAccountName, Name, LastLogonDate, DistinguishedName |
  Sort-Object LastLogonDate

Accounts that have never logged on at all have no lastLogonTimestamp. This LDAP filter returns enabled user accounts with no recorded logon:

Get-ADUser -LDAPFilter '(&(objectCategory=person)(objectClass=user)(!(lastLogonTimestamp=*))(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' `
  -Properties whenCreated, PasswordLastSet |
  Select-Object SamAccountName, whenCreated, PasswordLastSet

Two cautions. lastLogonTimestamp is replicated with a deliberate delay, so treat it as accurate to within a couple of weeks, which is fine for finding accounts idle for months or years. And an account that logs on only through some remote access paths may still update it, so do not use "recent logon" as proof that an account is legitimate. "Test2" was used in the weeks before the attack.

3. Find old passwords and accounts the policy never touched

This is the check that would have caught "Test2" directly. Any enabled account whose password was set before your current password policy came into force has never been tested against it.

$policyDate = Get-Date '2020-01-01'   # set to the date your current policy took effect
Get-ADUser -Filter 'Enabled -eq $true' -Properties PasswordLastSet, whenCreated, PasswordNeverExpires |
  Where-Object { -not $_.PasswordLastSet -or $_.PasswordLastSet -lt $policyDate } |
  Select-Object SamAccountName, whenCreated, PasswordLastSet, PasswordNeverExpires |
  Sort-Object PasswordLastSet

Also look for accounts flagged as not requiring a password, and for passwords set never to expire, which the Data Cymru policy applied to everyone:

Get-ADUser -Filter 'PasswordNotRequired -eq $true -and Enabled -eq $true' | Select-Object SamAccountName
Search-ADAccount -PasswordNeverExpires -UsersOnly | Where-Object { $_.Enabled } | Select-Object SamAccountName

"Never expires" is a common and defensible setting on its own. It becomes a problem when combined with no MFA, no deny list and no review, because then a weak password stays valid forever.

4. Search for names that mean "temporary"

Test, migration and demo accounts tend to follow naming habits. Search for them:

Get-ADUser -Filter 'Enabled -eq $true' -Properties whenCreated, LastLogonDate, Description |
  Where-Object { $_.SamAccountName -match '(?i)test|temp|tmp|demo|trial|migr|setup|install|old|svc' -or
                 $_.Description -match '(?i)test|temporary|migration|do not use' } |
  Select-Object SamAccountName, whenCreated, LastLogonDate, Description

Expect false positives for real service accounts. The point is to get every hit in front of a named owner who can say "this is mine and I still need it", or have it disabled.

5. List everyone who can reach the network from outside

Find the groups that grant VPN or remote access and list every member, including nested ones. Group names vary; replace the example with yours.

Get-ADGroupMember -Identity 'SSL VPN Users' -Recursive |
  Where-Object objectClass -eq 'user' |
  Get-ADUser -Properties Enabled, LastLogonDate, PasswordLastSet, whenCreated |
  Select-Object SamAccountName, Enabled, whenCreated, LastLogonDate, PasswordLastSet

Every member should have a named human owner, MFA enforced at the VPN, and a reason to be there. If your VPN authenticates through RADIUS on Network Policy Server, its grant and deny events (6272 and 6273) give you per user history to compare against this list.

6. Disable, do not delete, and record why

Disable first so you can reverse a mistake, move the account to a quarantine OU, and stamp the reason:

$acct = 'Test2'   # example
Disable-ADAccount -Identity $acct
Set-ADUser -Identity $acct -Description "Disabled $(Get-Date -Format yyyy-MM-dd) by account review, ticket 1234"
Get-ADUser -Identity $acct | Move-ADObject -TargetPath 'OU=Quarantine,DC=example,DC=org'
Get-ADGroupMember 'SSL VPN Users' | Where-Object SamAccountName -eq $acct |
  ForEach-Object { Remove-ADGroupMember -Identity 'SSL VPN Users' -Members $_ -Confirm:$false }

Delete after an agreed holding period. For accounts you keep, force a password change so the current policy applies (Set-ADUser -Identity <name> -ChangePasswordAtLogon $true), or set a new long random password if it is a service account.

7. Remove shared local administrator passwords with Windows LAPS

Windows LAPS is built into Windows Server 2019 and later and supported Windows clients that have the April 11, 2023 update, at no extra cost. It gives each machine a unique, rotating local administrator password stored in Active Directory or Entra ID. A typical on premises rollout:

# One time, on a domain controller, as Schema Admin
Update-LapsADSchema

# Let computers in an OU write their own password
Set-LapsADComputerSelfPermission -Identity 'OU=Servers,DC=example,DC=org'

# Then enable the Windows LAPS Group Policy for that OU:
#   Configure password backup directory = Active Directory
#   Enable password encryption = Enabled

# Afterwards, read a machine's current password (authorised admins only)
Get-LapsADPassword -Identity SRV-FILE01 -AsPlainText

To find machines not yet covered, look for computers with no Windows LAPS expiry time set:

Get-ADComputer -Filter 'Enabled -eq $true' -Properties 'msLAPS-PasswordExpirationTime', OperatingSystem |
  Where-Object { -not $_.'msLAPS-PasswordExpirationTime' } |
  Select-Object Name, OperatingSystem

The reprimand lists a primary domain controller among the three systems sharing a local administrator password. Domain controllers do not keep ordinary local accounts; their local fallback is the Directory Services Restore Mode account, and Windows LAPS can manage and back up that password too, so include your domain controllers in the rollout. Microsoft notes the legacy LAPS product is deprecated on Windows 11 23H2 and later, so use the native feature.

8. Block common passwords at the point of change

Microsoft Entra Password Protection extends Entra's global banned password list and your custom list to on premises domain controllers. Two details matter for this case. It checks passwords only on change and reset, so it would not have caught "Password1" on an account whose password never changed; you need step 3 and a forced reset as well. And it is enforced only on domain controllers where the DC agent is installed, so a partial rollout leaves gaps.

9. Put MFA on every remote entry point

Both organisations' fixes put the VPN behind Entra ID with MFA. That is the single change that turns a guessed password into a failed login. Check every way in, not just the main VPN: remote desktop gateways, webmail, provider support tools and any legacy portal that still authenticates against the directory directly.

10. Watch for spraying

Spraying shows up as one source trying many usernames with few attempts each. On domain controllers, event 4625 with sub status 0xC000006A (bad password) or 0xC0000064 (no such user) across many accounts from one address is the pattern. A quick look at the last day:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} |
  ForEach-Object {
    $d = ([xml]$_.ToXml()).Event.EventData.Data
    [pscustomobject]@{
      Time = $_.TimeCreated
      User = ($d | Where-Object Name -eq 'TargetUserName').'#text'
      Src  = ($d | Where-Object Name -eq 'IpAddress').'#text'
      Sub  = ($d | Where-Object Name -eq 'SubStatus').'#text'
    }
  } |
  Group-Object Src |
  Where-Object { ($_.Group.User | Sort-Object -Unique).Count -ge 10 } |
  Select-Object Name, Count, @{n='Users';e={($_.Group.User | Sort-Object -Unique).Count}}

VPN spraying often shows up first in the VPN appliance's own logs rather than on domain controllers, so forward those too. Microsoft's guidance for 4625 also recommends watching every failed logon for local accounts on critical servers, since those accounts should rarely fail.

11. Fix the contract

Read the agreement with every provider that can create accounts in your directory. Confirm it covers the Article 28(3) terms the Data Cymru reprimand lists, and add an explicit clause on who reviews all accounts, how often, and who removes provider created accounts when a project ends. The ICO release asks organisations to define security responsibilities clearly in contracts with IT providers and sub-processors.

What changed since the first reports

The incident itself was not public in detail until the reprimands. Data Cymru's website carries a short, undated notice describing a ransomware attack that disrupted operations (the page refused our connection when we tried to re-check it), but the account names, password, data volumes and the shared local administrator password only became public on 20 October 2026. Coverage since then has been consistent: The Register, Infosecurity Magazine and Nation.Cymru all report the same figures as the ICO release.

One wording point is worth knowing. The ICO release and the reprimands say "Password1" could be compromised in under a second, citing a third-party strength checker. That is a tool estimate, not a measured attack time; we use the ICO's wording only.

The other change is institutional. Both reprimands are issued in the name of the Information Commission, not the Information Commissioner. The Data (Use and Access) Act 2025 abolished the office of the Commissioner and moved its powers to a Commission on 30 September 2026. The Notices of Intent in August were issued under the old structure; the final reprimands under the new one.

Open questions

• Was "Test2" ever disabled? ONL's answer to the ICO allows two readings: active since 2012, or reactivated by mistake before 2024. If it was reactivated, the question becomes what process re-enabled a dormant test account and why that went unnoticed.
• How was the first server breached? The reprimand explains lateral movement through shared local administrator hashes, but not how a basic user reached local administrator on the first host.
• What did the six weeks before encryption look like? Activity on "Test2" from 20 September and "testtest" from 24 September suggests the attacker had time. The public text does not say what detection was in place.
• What happened with "testtest"? It is mentioned for suspicious activity but not described further.
• What data was in the two projects? The ICO has not published the data categories.

What would have helped

The ICO's own list is short: remove test, dormant and former user accounts; block weak and common passwords; require MFA for remote access; review all accounts, permissions and security groups; use unique credentials for privileged accounts; define responsibilities in contracts. The reprimands record that both organisations have since put several of these in place. None of what follows is a judgement on either organisation beyond what the regulator found. It is what any team can take from the case.

Practices any team can use

The commands in the previous section cover the directory itself. Beyond them:

• Give every account an owner and an end date. Create test and migration accounts with an expiry date (Set-ADAccountExpiration) so they turn themselves off when everyone forgets.
• Treat remote access group membership as privileged. Low rights inside the domain do not make an internet facing login low risk.
• Retest old passwords against the current policy. A policy that only checks at change time leaves every older password unchecked.
• Write account hygiene into provider contracts. Who reviews, who removes, how often, and how the customer gets evidence that it happened.
• Keep logs long enough to see a slow intrusion. The joint MSP advisory recommends keeping the most important logs for at least six months. Here, the first sign came six weeks before encryption.
• Test restores. The reprimands do not discuss backups, but with 182.7GB encrypted, recovery time depends on how recently you proved a restore works.

Zero-Day Discovery and Gold

This incident had no software vulnerability in it, so it is worth being clear about what two Safeguard capabilities do and do not cover.

Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists, in two modes, an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. It does not look at Active Directory accounts, passwords or VPN configuration, and there is no package flaw in this case for it to find.

Gold Open Source at gold.safeguard.sh is free and needs no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is a paid service of hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge if it regresses. There is no CVE in this incident to look up.

The habit these support is still relevant to a team that just learned its VPN or directory had been left alone for years: when an advisory does land for a component you run, pull a patched, signed build from a curated source and rebuild quickly, rather than leaving it for the next annual review.

Where Safeguard fits

Be clear about the limits first. Safeguard does not audit Active Directory, find stale accounts, rotate local administrator passwords, enforce MFA on a VPN or detect password spraying. Those are jobs for your directory, your identity provider and your logging. We do not claim Safeguard would have prevented this incident.

What Safeguard does offer that touches the governance side of the problem:

• The compliance and GRC suite tracks frameworks, controls, evidence, tests, risks and vendors in one place, with connectors that pull evidence from systems you already run. Account review and MFA on remote access are controls in most frameworks; recording them as controls with owners and evidence turns "we do reviews sometimes" into a dated record you can show a regulator.
• Third-Party Risk Manager lets you onboard vendors such as a managed service provider and keep their documents and assessments with the vendor record, which is where an Article 28 contract and its review date belong.
• Agent identity tracks which AI agent holds what access and at what level. As teams give agents and automation accounts into their systems, those identities need the same owner and end date as a human test account.
• The Safeguard CLI's assistant can write and run the audit scripts above with your approval. It edits code and runs commands only as you allow under /permissions (Ask, Accept edits, Plan, Auto, the default, and Strict), and safeguard exec runs it in CI. Desktop and phone apps can send work to a computer running the CLI and approve each command.
• For the software you build, SBOM and dependency scanning of repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, with JSON results under ./output), vulnerability matching, reachability analysis, policies and gates, and autonomous remediation with fix pull requests (off by default) cover the component side, which is a different risk from the one in this case.

Common mistakes and troubleshooting

• Reviewing one group. "Domain Users" is the default primary group, but accounts can sit outside it or in OUs nobody looks at. Export everything.
• Trusting the password policy to cover old passwords. Policies apply on change. An account that never changes its password is never checked.
• Assuming no admin rights means low risk. "Test2" had none. VPN access plus shared local admin hashes were enough.
• Deleting accounts on day one. Disable, quarantine and wait. Deleting a service account that something still uses causes an outage and loses the SID.
• Rolling out a password filter on some domain controllers. Entra Password Protection only enforces where the DC agent is installed. Clients pick whichever DC they reach.
• Using legacy LAPS on new systems. It is deprecated on Windows 11 23H2 and later and stores passwords in clear text in the directory; native Windows LAPS supports encryption and history.
• lastLogonTimestamp looks wrong. It replicates with a delay by design. For exact last logon per DC, query lastLogon on each DC, but for stale account hunting the replicated value is fine.
• Get-LapsADPassword returns nothing. The machine has not processed policy yet, the OU lacks self permission, or you lack read rights on the encrypted attribute. Check the Windows LAPS event log channel on the device.
• Leaving provider created accounts out of scope. If your provider can create accounts, those accounts are yours to review too.

FAQ

What happened at Data Cymru?

On 1 November 2024, according to the ICO, a ransomware attacker who had got in through a test account called "Test2" encrypted 182.7GB of data after taking 42GB from a domain controller, a file server and an SQL server. Personal data of 3,300 people, mostly children, from two projects supporting children and families was taken.

Why was the password "Password1"?

The reprimand says ONL set it when it created the "Test2" account on 13 January 2012 to test user access before migrating real users. Data Cymru's later 15 character policy never applied because the account's password was never changed.

Who is Ogi Networks and why was it reprimanded?

Ogi Networks Limited is a Cardiff network provider that has supplied Data Cymru's managed IT since 2012. The ICO found it infringed Articles 32(1)(b) and 32(1)(d) by not applying adequate password standards and not auditing accounts it created in Data Cymru's network, including local administrator accounts left on one shared password for over 12 years.

Why was Data Cymru reprimanded as well?

Data Cymru controlled the network and could instruct ONL to create or remove accounts. The ICO found it had no Article 28 compliant contract with ONL until 30 April 2025, did not define how the directory service would be monitored or audited, and ran account reviews that were not scheduled and did not cover all of Active Directory.

Was there a fine?

No. Both organisations received reprimands. The ICO says it considered the seriousness of the breach, the number of people and categories of data, the public interest and the remedial steps both organisations took.

How did the attacker get in?

The investigators found initial access through an SSL VPN connection using the "Test2" username. The ICO says the account was likely compromised by password spraying, trying one common password across many accounts.

How did a basic user account reach the domain controller?

The reprimand says the local administrator accounts on the three affected systems shared one password. Once one system was breached, local account hashes could be collected and reused to authenticate to the others. It does not explain how the first system was reached.

Has the stolen data been published?

The Data Cymru reprimand says Tarian, the regional organised crime unit, and the NCSC have been monitoring and there is no evidence of publication to date.

What is the Information Commission?

Under the Data (Use and Access) Act 2025, the office of the Information Commissioner was abolished on 30 September 2026 and its powers moved to the Information Commission, which decides through a board. The ICO now acts on the Commission's behalf. These reprimands were issued under the new structure.

Fix it without waiting for upstream

This incident was about identities, not packages, so this section applies to a different part of your estate: the open source dependencies and container images you build and ship. The same habit of leaving known problems in place for years shows up there too.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows Data Cymru, Ogi Networks or an Active Directory audit. Each is a real Safeguard session, and each intro explains how the same flow applies to the work in this post.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For this incident, you would open the CLI in the repository where you keep your admin scripts and ask it to write the stale account and password age queries from this post as one report script, then approve each command it runs against a test domain first.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Here you would pick your Group Policy or infrastructure folder, ask for a change such as adding a Windows LAPS policy for the servers OU, and approve or deny every edit yourself, which keeps a human in the loop on exactly the kind of change that went unreviewed for twelve years.

Click through it at your own pace, or open it full screen.

This session connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It is the same principle the reprimands turn on, applied to an AI assistant: grant only the access a task needs, and know who holds it, rather than leaving a broad account in place because nobody decided otherwise.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI docs. For another case where a provider relationship shaped the outcome, read IDCF Cloud ransomware and third party risk. For remote access devices under attack this month, see edge device zero days in October 2026, and for the wider month, October 2026 security incidents and what would have helped.

Quick check

Sources

• ICO: "Password1 is not an appropriate password" (news release, 20 Oct 2026)
• ICO: Reprimand to Ogi Networks Limited (dated 14 Oct 2026, scanned PDF)
• ICO: Reprimand to Local Government Data Unit, Wales (dated 14 Oct 2026, scanned PDF)
• The Register: Password1 and a forgotten test account land Welsh outfits in hot water (20 Oct 2026)
• Infosecurity Magazine: children's data stolen after Password1 used on test account (21 Oct 2026)
• Nation.Cymru: Two Welsh organisations reprimanded after cyber attack exposed children's information (20 Oct 2026)
• CISA and partners: AA22-131A, Protecting Against Cyber Threats to Managed Service Providers and their Customers (11 May 2022)
• Microsoft Learn: Windows LAPS overview
• Microsoft Learn: Microsoft Entra Password Protection for on premises AD DS
• Microsoft Learn: Search-ADAccount
• Microsoft Learn: Event 4625, An account failed to log on
• NCSC: Multi-factor authentication for your corporate online services

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.