How the cybersecurity perimeter has shifted
15/10/2026
By Robert Lintun, Senior Cybersecurity Engineer and Umbrella Club member
For most of my career, cybersecurity meant defending a perimeter. You built strong walls around the network, watched the gates carefully, and everything inside those walls was, broadly speaking, trusted. That model made sense when a business’s infrastructure sat largely on-premises, inside a building you could point to.
That model doesn’t reflect how businesses actually operate anymore. The perimeter hasn’t just moved, it’s been redefined entirely, and a lot of organisations are still securing the version of their business that existed five years ago rather than the one they’re actually running today.
The old model: walls around the network
Before cloud, security was almost entirely about parameter defence. Firewalls, the DMZ, network policy, all built around a fairly simple idea: keep threats outside the perimeter, and trust what’s inside it. That approach worked reasonably well when infrastructure was physically on-premises and the boundary between ‘inside’ and ‘outside’ was clear.
How the security model used to be structured:
| Element | Role in the old model |
|---|---|
| Firewall | Primary gatekeeper between internal network and the outside world |
| DMZ | Buffer zone for anything that needed limited external exposure |
| Network policy | Rules governing what could talk to what, inside a defined boundary |
| Trust model | Largely binary: inside the network was trusted, outside wasn’t |
The turning point: cloud transformation, accelerated by COVID
Cloud transformation changed all of that, and COVID accelerated the shift dramatically. Once organisations moved their infrastructure to the cloud, the old perimeter simply stopped existing in any meaningful sense. There was no longer a clear physical or network boundary to defend, because the business itself no longer operated inside one.
That forced a genuine shift in where the first line of defence actually sits. It moved away from the on-prem firewall and those traditional IT defence mechanisms, toward identity. In a cloud-first world, identity is the new perimeter. Who someone is, and what they’re authorised to access, matters more than which network they happen to be connecting from.
The new front line: identity
This is the shift I think a lot of businesses still haven’t fully internalised. Identity isn’t just one part of the security stack anymore, it’s effectively become the first line of defence. If an identity is compromised, the attacker doesn’t need to breach a firewall at all, they simply operate as if they belong there.
That changes what ‘good security’ actually looks like day to day. It’s less about the strength of the wall and more about how tightly access is controlled, monitored, and verified at the identity level, continuously, not just at the point of login.
The emerging complication: AI-enabled threats
Layered on top of that identity shift is a newer and more difficult problem: AI-enabled threats. We now have agents capable of manipulating systems and escalating malicious activity in parallel, at a speed and scale that traditional monitoring wasn’t built to catch.
We’re in an era where the tricky part isn’t recognising that AI-driven threats exist, most security teams know that already. It’s figuring out how to identify and address them effectively without costing the organisation a fortune in the process. That’s not a hypothetical challenge anymore, it’s a real, current cost and resourcing problem that security leaders are having to solve in real time.
I’d sum up the core discipline of this work fairly simply: security is about finding the needle in the haystack, and knowing which needle you’re actually looking for, and in which haystack. AI threats haven’t changed that fundamental task, they’ve just made the haystack considerably bigger and faster-moving.
DevSecOps: the practical response
The industry’s practical answer to a lot of this has been DevSecOps. Everything has become automated, everything is deployed through code, and people now need to be genuinely proficient in deploying using templates and code as standard practice. That discipline standardises an organisation’s entire infrastructure and helps prevent the kind of configuration drift that quietly creates vulnerabilities over time.
What DevSecOps actually changes in practice:
- Security checks get built into the deployment pipeline itself, rather than added as a separate step afterward
- Infrastructure is defined and deployed through code, making configuration consistent and auditable
- Vulnerabilities are far more likely to be caught before code reaches production, not after
- Configuration drift across environments becomes far less likely when everything follows the same coded template
The governance risk inside AI-assisted development
Here’s where it gets genuinely difficult. With the rise of AI, people can now generate code far faster than they used to. That’s a real productivity gain. But it raises a question the industry hasn’t fully answered yet: how do you govern code that AI wrote?
It’s not just about whether the code works. It’s about the quality of that coding, and the security of it. AI-generated code can introduce vulnerabilities just as easily as it can save time, and in my experience, most organisations are moving faster on AI-assisted development than they are on the governance needed to keep it safe.
This is really a shift-left problem. The earlier you can catch and prevent an issue in the software development lifecycle, the cheaper and safer it is to fix. Waiting until code is already in production to discover a problem is the most expensive place to find one.
Why the human factor still can’t be automated away
There’s a well-known example that illustrates exactly why human oversight still matters, no matter how mature your automation is. The 2024 global CrowdStrike outage, which took down huge numbers of Windows devices worldwide, happened because a flawed update was pushed into production environments without enough safeguards catching the problem before it caused widespread disruption.
I use that example deliberately, because it’s a reminder that relying on automation without a human checking critical changes before they go live is a real and recurring risk, not a rare one. You can’t ignore the human factor at all. Every revolution in this industry comes with both threat and opportunity, and AI is no different. Organisations can automate and deploy agents to save cost, but they can’t fully trust automation or trade away human oversight and still call their security posture mature.
What this means for businesses right now
The perimeter isn’t gone, it’s just moved, more than once, and it’s still moving. Identity is the current front line. AI is reshaping both the threat landscape and the tools defenders have available. And the organisations that handle this well aren’t necessarily the ones with the biggest security budgets, they’re the ones that have kept governance and human oversight moving at the same pace as their adoption of new technology.
That’s the gap I spend most of my time helping organisations close: not just implementing the tools, but making sure there’s a clear, accountable structure around how they’re governed and used.
If your organisation is navigating cloud transformation, identity security, or the governance challenges that come with AI-assisted development, contact Umbrella Club to arrange a conversation with me.
Robert Lintun is a Senior Cybersecurity Engineer with more than 15 years’ experience across security operations, identity and access management, and DevSecOps. His background spans SIEM/SOC onboarding and uplift, IAM and PAM projects, and digital transformation work across sectors ranging from non-profit to defence. Robert recently transitioned from permanent employment to contracting, bringing broad, cross-industry security expertise to organisations navigating cloud transformation and emerging AI-driven threats. He is a member of Umbrella Club.
