Why Hackers Don’t Hack Firewalls Now – They Hack You

The network perimeter is gone – what replaced it?

Let's rewind to the classic enterprise network diagram for a moment. Users sat inside a corporate LAN. Apps lived in your own data centre. Internet access went through a few choke points where you could inspect, filter and log. The model was simple:

• Inside = trusted. Devices on the corporate network were assumed to be safe.
• Outside = untrusted. The internet was where the threats lived.
• Firewalls drew the line. Your job was to keep “outside” out and “inside” in.

That mental model breaks the moment you add:

• Cloud apps (SaaS) that users access directly over the internet.
• Remote and hybrid work from unmanaged networks and devices.
• Partners, contractors and customers that need access to your apps.
• Mobile devices that may never touch your physical offices.
• APIs and machine identities talking between clouds and services.

In that world, users spend most of their day outside your old perimeter, talking to systems that are also outside your data centre. And yet they're doing extremely sensitive work: approving invoices, pushing code, handling patient data, managing infrastructure.

The result: the question “Is this packet coming from inside or outside the firewall?” matters far less than “Who is this, and what context are they coming with?”

How attackers really “hack you” instead of your firewall

If you look at real incident reports today, a pattern jumps out: most successful intrusions don't start with a novel zero-day against your core firewall. They start with identity misuse.

Common identity-driven entry points include:

1. Phishing and credential theft

• Classic email phishing and lookalike login pages trick users into typing credentials into the wrong place.
• Attackers reuse stolen passwords against cloud services, VPNs and admin portals, often succeeding thanks to password reuse and weak factors.

2. MFA fatigue and prompt bombing

• When attackers already have a username and password, they can spam push-based MFA prompts until a tired or distracted user taps "Approve" just to stop the noise.
• Social engineering (“It's IT, we're just testing a new system, please approve the next prompt.”) amplifies this effect.

3. Session and token theft

• Malware or browser stealing tools can grab session cookies and tokens from a logged-in browser, letting attackers bypass the login screen altogether.
• Once a valid session token is stolen, many apps don't distinguish it from a legitimate session until you explicitly revoke or re-evaluate it.

4. OAuth and consent abuse

• Instead of stealing your password, an attacker gets you to grant a malicious app access to your mailbox, files or calendar via a legitimate consent screen.
• The result is a backdoor that persists even if you change your password or enable MFA, because the app itself now has its own tokens.

5. Supply chain and admin abuse

• Compromising an MSP, SSO provider or IdP admin can give attackers wide access to downstream tenants and apps.
• Over-privileged service accounts and shared admin logins act as super-keys that, once stolen, make lateral movement trivial.

None of these require “hacking the firewall.” They rely on something much simpler: the system believes the attacker is you. That is why the modern perimeter is identity.

Identity as the new perimeter: what that actually means

Saying "identity is the new perimeter" can sound like marketing. Let's make it concrete.

In an identity-first world, the critical enforcement point is no longer a specific piece of network hardware. It's your identity platform and the frameworks around it:

• Your identity providers (IdPs) and SSO platforms.
• Your MFA mechanisms and conditional access policies.
• Your session, token and device trust models.
• Your joiner/mover/leaver processes for accounts and permissions.

Every request to read, write or change something important should go through a flow that answers:

• Who is asking? (human, device, service, agent)
• How did they prove it? (password, phishing-resistant MFA, certificate, key, hardware)
• From where are they asking? (known device/location? anonymous TOR exit?)
• For what exactly? (fine-grained action, not just “access”)
• Should they still have this ability right now?

The perimeter becomes dynamic, wrapped around each identity and each request rather than around a building or IP range.

Zero Trust in one sentence (and what people get wrong)

At its simplest, Zero Trust is:

Never trust, always verify — and assume breach.

That means:

• No implicit trust just because something is on a “trusted network”.
• Every access is authenticated, authorised and logged, based on identity and context.
• Access is limited to what's necessary, and re-evaluated as context changes.

Common misunderstandings:

• “Zero Trust is a product.” It isn't. Vendors can help, but Zero Trust is an architecture and mindset that cuts across identity, devices, networks, apps and data.
• “Zero Trust means trusting nothing, ever.” In reality, you are still making trust decisions — you're just making them continuously and based on stronger signals, not one-off assumptions.
• “Zero Trust replaces everything we have.” In most organisations, it's an evolution, not a rip-and-replace. You build Zero Trust around and on top of what exists.

Identity is the pillar that makes Zero Trust workable. You can't enforce “least privilege per request” if you have no reliable way to know who or what is making the request.

Identity-first security: core building blocks

So what does an identity-first, Zero Trust-aligned stack actually look like? The details differ by size and sector, but most mature environments share the same building blocks.

1. A strong, central identity platform

• Consolidate identities (where possible) into one or a small number of well-managed IdPs for workforce, customers and machines.
• Avoid orphaned local accounts and shadow directories that bypass central policies and visibility.

2. Secure, user-friendly authentication

• Enforce MFA for all users where practical, prioritising admins and high-value roles first.
• Move towards phishing-resistant methods (FIDO2/WebAuthn, security keys, platform authenticators, certificates) instead of pure SMS or app-push fatigue magnets.
• Use single sign-on (SSO) to reduce password sprawl and make secure behaviour easier than insecure workarounds.

3. Conditional access and continuous evaluation

• Don't treat all logins the same. Evaluate risk based on location, device posture, user role, time-of-day, sensitivity of the resource, and anomalies.
• Step up auth (extra factor, re-prompt) for high-risk scenarios or sensitive actions, not just on first login.
• Periodically re-check long-lived sessions instead of letting them live forever until logout.

4. Least privilege and just-in-time access

• Replace always-on admin rights with time-bound, just-in-time elevation that requires approvals or strong factors.
• Regularly review group memberships, roles and entitlements, especially for shared or service accounts.
• Use role-based and attribute-based access controls (RBAC/ABAC) to simplify policy management at scale.

5. Device and workload identity

• Treat devices and workloads as identities too. Laptops, servers, containers and functions should all have their own strong credentials, certificates or keys.
• Verify device posture where possible (OS version, security tooling, disk encryption) before granting access to sensitive apps or data.

6. Governance, lifecycle and monitoring

• Automate joiner/mover/leaver flows from HR or source-of-truth systems so accounts and access don't linger after roles change.
• Log identity events centrally (logins, consent, privilege escalations, failures) and feed them into your detection and response tooling.
• Monitor for impossible travel, unusual consent grants, sudden role changes, and bursts of failed logins.

Identity-first doesn't mean "ignore everything else." It means acknowledging that in a cloud-first, hybrid world, identity is where your most consequential security decisions now happen.

A practical roadmap to identity-first Zero Trust

It's easy to get overwhelmed by Zero Trust diagrams with dozens of boxes. In reality, most organisations progress through a few pragmatic stages. Here's a simplified roadmap you can adapt.

Stage 1 — See reality clearly

• Inventory identity stores: AD, Entra/Okta/other IdPs, local accounts, SaaS-native users.
• Inventory high-value apps, admin consoles, and data stores — who can access them and how.
• Baseline current auth methods: where passwords, MFA, SSO and legacy protocols are used.

Stage 2 — Fix the obvious risks

• Enable MFA for admins and remote access first, then expand to all users.
• Turn off legacy protocols where possible (basic auth, older mail protocols without modern auth).
• Start consolidating shadow SaaS into SSO and your central IdP.

Stage 3 — Apply conditional access and better signals

• Introduce simple conditional access policies: block risky geos, require compliant devices for sensitive apps.
• Pilot phishing-resistant methods for small groups (IT, execs, high-risk teams) and expand based on feedback.
• Integrate identity logs with your SIEM/SOAR and build initial detections for identity abuse patterns.

Stage 4 — Shift to least privilege and just-in-time

• Audit standing admin roles, shared accounts and powerful groups; reduce where possible.
• Roll out just-in-time elevation, approval workflows, and access reviews for critical roles and apps.
• Build processes for rapid revocation of tokens, sessions and access in response to suspected compromise.

Stage 5 — Continuously improve & extend

• Extend identity-first principles to machine identities, APIs, CI/CD pipelines and automation accounts.
• Refine policies based on real-world incidents and detections — learn from every near miss.
• Align with a recognised Zero Trust maturity model to communicate progress to leadership and regulators.

You don't need to be "perfectly Zero Trust" to get massive risk reduction. Each stage buys you resilience against the most common, identity-driven attack patterns — long before you tick every box on a framework slide.

Data snapshots: identity-driven attacks (sample charts)

To visualise why identity matters so much, here are two simple sample datasets: one showing typical initial access patterns in breaches, and another showing a rough maturity journey from password-only to phishing-resistant identity-first controls.