A decade ago, many discussions about enterprise security fortification could be mapped out rather simply: here is the corporate network, there is the outside world, and between the two lies the perimeter boundary. In effect, it took the shape of a moat around the castle that is a corporate network.
Unfortunately, that map has been eroded by permanent shifts in how modern organizations operate. Remote and hybrid work, global SaaS adoption, cloud-native development, and the rise of edge and IoT deployments have created environments where critical systems are distributed across infrastructure that is not centrally owned or consistently managed.
In that setting, the traditional perimeter has become fragmented. Connections originate from homes, hotels, shared workspaces, factories and field sites. Workflows run across third-party platforms, and applications depend on APIs and services that traverse multiple administrative domains. The approach is practical and efficient, but it breaks security assumptions built around a single front door.
A common response is to build for functionality first and add security later. It delivers short-term momentum, but it creates architectures that are brittle to defend and expensive to maintain, with compensating controls, exceptions and manual processes layered over decisions that were never made with sustained adversarial pressure in mind.
As environments have become more disaggregated, identity has shifted from an enabling layer to the primary control plane. Access decisions are made per user, per device, per workload and per session across platforms with different policies and administrative models, expanding the attack surface.
Human identity is rarely as coherent as security frameworks imply. Privileges build up across SaaS tools, directories and contractor accounts. Offboarding can be uneven, and temporary access can become long-term access that sits silently in the background. Credential theft remains one of the most reliable attack paths because it scales and because identity signals are often treated as routine IT issues rather than security events.
Machine identity adds scale and complexity. Service accounts, tokens, certificates and keys proliferate across cloud workloads, edge gateways, scripts and integrations. These credentials are frequently created to remove friction, then left in place with broad privileges because tightening them risks breaking services. The combination of volume, privilege and limited lifecycle management creates attractive targets for attackers seeking inconspicuous, persistent access.
Secure by design, in principle
Security controls added after the fact can increase complexity without reducing risk. Each new layer addresses an immediate gap, but also introduces dependencies and failure modes. Exceptions become permanent infrastructure, and security drifts toward institutional memory held by a small number of individuals. Costs accumulate through brittle integrations and high-touch administration, and incident response often uncovers undocumented trust relationships and access pathways that were never designed for containment.
Secure by design is intended to reverse this dynamic, but it needs a practical definition. Ideally, it should describe an architectural approach that reduces implicit trust, minimizes special cases, and assumes components and credentials will eventually be compromised.
A practical definition begins with three assumptions. The first is that compromise is inevitable. Credentials will leak, software will contain flaws, supply chains will be targeted, and administrative accounts will be pressured.
The second assumption is that implicit trust must be minimized. Access should be verified explicitly, privileges should be constrained to what is necessary, and lateral movement should be limited so that a single compromised identity does not become a universal key.
The third assumption is that security must be engineered for change as organizations integrate new platforms, retire old systems and update cryptography without turning every shift into a high-risk, business-stalling migration.
Secure by design, in practice
The most reliable path starts by treating machine identity as first-class. Services, workloads, devices, and APIs require the same discipline applied to human users: issuance, governance, and retirement. Long-lived secrets should be reduced wherever possible, privileges should be function-specific, and identity lifecycle management should be designed into operational processes rather than delegated to ad hoc fixes.
Encryption should also be treated as a foundation of secure operations. Standardized, strong configurations for data in transit across cloud, on-premises, and edge environments reduce exposure and limit the number of judgment calls required from individual teams. That starts with clear visibility into the protocols in use, creating the baseline for the crypto-agility required to keep security viable at scale.
The moat-and-castle model offered comfort because it implied one boundary and one place to defend. Going forward, that comfort is a liability. When critical workflows and identities are distributed, security has to be engineered into the system itself. Secure by design means consistent identity governance that includes machines, encryption that is applied as a default, and the ability to contain compromise without disruption. Employed properly, this helps businesses to build an environment that remains defensible when the map no longer matches the territory.
By Michael Murphy, Deputy CTO, Arqit