How it gets built

Nobody sets out to build an insecure account. A data science team, or a contractor, or the founder two years ago, needed somewhere to work that was not production. An account was created. A few instances were launched by hand, because the infrastructure-as-code pipeline did not exist yet or did not cover this account. Someone opened SSH from their home IP, then from anywhere because the IP changed. A database was exposed so a notebook could reach it. The work got done and the team moved on.

Every step was reasonable. Nothing was decided badly. The account simply never went through the process the production account went through, because at the time there was no process, and later nobody went back. The NCSC's annual review says most successful attacks still exploit familiar weaknesses, and names known vulnerabilities in internet-facing systems first. This account is where those live.

Why "it is only dev" is wrong

The accounts share more than their owners think. The same identity provider, so a credential that works in one often works in the other. A network peering set up for a data pipeline. A CI system holding deployment credentials for both. A copy of production data taken for a realistic test, still there. The scan findings that look like technical debt, missing multi-factor authentication on identity roles left over from a migration, are the same findings an attacker needs, whether or not anyone has recorded them as accepted risk.

Once inside an account with no monitoring, the attacker's question is only what it can reach. The answer is usually more than anyone wrote down, because nobody wrote it down.

The production account is secured because someone owns it. The neighbouring account is insecure because nobody does. Ownership, not tooling, is the difference, and ownership is a decision that has to be made on purpose.

Rebuild it. Do not patch it.

The instinct is to work through the findings: close the security groups, add the MFA, retire the keys. In a manually built account that leaves you with a slightly better manually built account and a scan next quarter that finds the next layer. The fix that holds is a rebuild from infrastructure as code.

  1. Scan every account, not the one you watch. A read-only posture scan across the organisation, with findings ranked per account. The account nobody owns will be at the top, which is the point.
  2. Decide the account structure on purpose. A shared development account, then separate staging and production accounts per product or per customer, each with the same baseline. Isolation is cheaper than forensics.
  3. Rebuild the legacy account from code. Pick the infrastructure-as-code tool the team will actually maintain and recreate the account with the baseline enforced: no public SSH or RDP, no exposed data stores, MFA on every identity, logging on by default. Resources rebuilt this way often qualify for cloud migration programme funding, which is a useful argument when someone asks why.
  4. Put the guardrails above the account. Organisation-level policies that make the worst findings impossible in every account, including the next one someone creates on a Friday afternoon.
  5. Give it a name. An owner tag on every resource, a person on the rota for the account, and its findings in the same backlog as production's, not in a separate list that is read on Mondays.
  6. Watch it the same way. Monitors and detections managed as code, routed to a human, with the same thresholds as production. An account with no monitoring is an account where the attacker's first week is quiet.

Where we fit

Critical Cloud scans the whole estate, not the account you already watch. A HealthScan runs read-only across every account and produces a ranked list per account. The Cloud Security accelerator puts continuous posture management in place with an ownership model in four weeks. The rebuild itself, the account structure and the guardrails above it are delivered through AWS and Azure engineering, and Critical Support keeps the baseline honest afterwards. One fintech customer came to us for a resilience review and left with every action ranked and owned, which is the shape this work should take.

We operate the stack. You own the product, and you own every account in it, including the one you forgot.

Frequently asked questions

Why is a development or data science cloud account a security risk if production is secure?

Because the accounts share more than people think: an identity provider, a network peering, a CI pipeline with credentials for both, a copy of production data taken for a test. An account with SSH or a database port open to the internet is the easiest way in, and once inside, the question is only what that account can reach. The NCSC's 2026 review names known vulnerabilities in internet-facing systems as one of the three most common ways attacks still succeed.

Should we fix the account or rebuild it?

If it was built by hand and nobody can say what is in it, rebuild it from code. Fixing findings one by one in a manually built account leaves the next one for the next scan. A rebuild from infrastructure as code gives you an account where the baseline is enforced, drift is visible, and every future change is a reviewed diff. It is also usually faster than the audit it replaces.

Does Critical Cloud scan and secure every account, not only production?

Yes. A HealthScan runs read-only across every account in the estate and produces a ranked list of findings per account, so the account nobody owns shows up next to the one everyone watches. The Cloud Security accelerator puts continuous posture management in place with an ownership model, and Critical Support carries the rebuild and the ongoing guardrails.

Sources

  • NCSC, Annual Review 2026: incident management, 3 November 2026, for the familiar weaknesses.
  • The account described is a pattern drawn from our own posture scans across customer estates. No customer is identified and no counts are published.