Identity Security: Why the Next Hacker Won't Break In—They'll Log In

---

At 8:17 on a Monday morning, a finance director receives a prompt to approve a sign-in on her phone. She is travelling, the company's remote-access system is familiar, and a colleague has just warned the team about an urgent supplier payment. She taps "Approve".

A few minutes later, an attacker is reading the finance mailbox from a device that looks ordinary, using a session that looks legitimate. They create a forwarding rule, find a recent conversation with a supplier, and reply in the same thread. No server is smashed. No firewall flashes red. No exotic vulnerability is required. The intruder has entered through a valid identity and is now moving through trusted workflows.

This is an illustrative scenario, not a documented incident. Modern compromise often begins not with a dramatic break-in, but with a successful login. The attacker's advantage is that the organization's systems are designed to accept the identity, token, permission, or relationship being presented.

---

The perimeter moved into the identity layer

The old mental model of cybersecurity starts at the network edge. We picture an attacker outside, a wall around the business, and a sequence of technical gates that must be forced open. That model still has value, but it no longer describes where much of the action happens.

Work is distributed across cloud platforms, SaaS applications, mobile devices, contractors, managed services, and home networks. Data travels through collaboration tools and application programming interfaces. A company's effective perimeter now includes every identity that can reach a resource, every device that can hold a session, and every process that can act on a person's behalf.

That changes the defender's central question. It is no longer only: "Can we keep an intruder out?" It is also: "Can we recognize when a legitimate identity is being used illegitimately, and can we limit what it can do?"

This is the core challenge of identity security: determining whether a legitimate identity is being used in a legitimate way, while limiting the potential impact when that trust is abused.

An account can be authentic while the activity is malicious. A token can be correctly issued while being used by someone else. A help-desk request can follow the right script while being engineered by a fraudster. An OAuth application can receive the consent it needs while quietly acquiring durable access to mail or files. Security teams must therefore distinguish authentication from assurance, and authorization from appropriateness.

---

A valid identity is not a verdict

Identity-based attacks work because organizations have spent years improving convenience and connectivity. Single sign-on, password managers, federation and self-service access are necessary foundations for modern work. But each creates a rich control plane. Once an attacker obtains a credential or session, the platform may help them move quickly and quietly.

There are several routes to that position:

• A convincing phishing page captures a password and attempts to relay the login in real time.
• An infostealer extracts passwords, browser cookies, tokens, or stored secrets from an employee's device, enabling credential theft and potential account takeover.
• A user approves repeated MFA prompts simply to make the interruption stop.
• A criminal persuades a support agent that an account recovery is urgent.
• A supplier or managed service provider is compromised, turning a trusted connection into a route towards customers.
• A leaked service-account secret grants access that no individual employee would normally receive.

These routes differ technically, but they converge operationally. The attacker wants an identity with enough legitimacy to pass controls, enough privilege to reach something valuable, and enough time to make their activity look like work.

The implication is not that employees are the weakest link. People are asked to make high-consequence security decisions in environments optimized for speed and plausible urgency. Better protection combines thoughtful design, reliable signals and humane processes; it does not simply tell users to be more suspicious.

Effective identity threat detection therefore needs to consider more than whether credentials were successfully presented. It must also consider the device, session, permissions, behaviour and business context surrounding the identity.

---

MFA is essential—and not sufficient

Multi-factor authentication remains one of the most important defensive measures an organization can deploy. It makes stolen passwords substantially less useful and raises the cost of many common attacks. Removing it, weakening it for convenience or treating it as a box to tick is indefensible.

Yet MFA answers a narrow question: can the person, device or process present the required factors at this moment? It does not automatically answer who is operating the session, whether the request is genuine, what the session can access, or whether the action fits the user's normal role and circumstances.

MFA fatigue illustrates the gap. An attacker with a password may generate a stream of approval requests until a tired or distracted user accepts one. The technical control functions as configured; the social system around it is manipulated. Number matching, rate limits, risk-based prompts and user education can reduce this exposure, but the stronger direction is phishing-resistant MFA based on cryptographic credentials, such as passkeys or security keys.

Phishing-resistant MFA should be the destination for workforce, administrator, and high-impact access. But it should not become an excuse to stop thinking. Attackers can target recovery flows, enrolled devices, help desks, identity administrators, and sessions established after authentication. MFA protects the entrance; it does not patrol the entire building.

A mature identity security strategy therefore combines MFA with continuous monitoring, access controls, device signals, and rapid response.

---

The session is the new prize

A password is a secret. A session is permission already in motion. If an attacker steals a browser cookie, access token, or refresh token, they may be able to act without repeating the original login. This is why adversary-in-the-middle attacks are so important: a lookalike site can sit between a user and the real service, relay authentication, and capture material that proves a session has been established.

This form of session hijacking demonstrates why authentication alone cannot provide complete security. Once a legitimate session exists, defenders need visibility into how that session behaves.

Infostealers widen the problem. Malware on a personal or corporate device can search browsers, password stores, cryptocurrency wallets, local files, and session data. A victim might change a password and remain exposed if a live token is valid or if another secret was copied at the same time.

Incident response must therefore include revoking sessions and refresh tokens, reviewing newly registered authentication methods, checking mailbox rules and application grants, and rebuilding trust in the device.

Defenders should monitor the life of a session, not only its birth. Useful signals include an impossible or unusual change in device characteristics, a new country or network combined with sensitive actions, a token used by an unfamiliar client, rapid access to many files, and access patterns that diverge from a person's working rhythm.

No single signal proves compromise; combined signals can reveal an identity behaving unlike itself.

The goal is not to demand a new challenge for every click. Endless prompts teach people to approve blindly. The goal is proportionate, continuous confidence: stronger friction when risk rises, quiet access when context is consistent, and rapid containment when confidence collapses.

---

Trust is being engineered at human speed

Social engineering has moved beyond badly written messages. Attackers can research organizational structure, imitate writing styles, spoof caller identity, and use voice or video manipulation to make an urgent request feel familiar. Generative AI can help produce credible correspondence at scale, but the underlying weakness is older: people trust a known name, a familiar process and a request that appears to come from authority.

Deepfakes need not be perfect to be useful. They only need to create enough confidence during a rushed payment approval, password reset, or executive meeting. Organizations should avoid framing this as a contest in which employees must detect visual artefacts.

Instead, high-impact actions need independent verification and separation of duties. A request to change bank details should be confirmed through a known channel. A privileged-access reset should require a documented, auditable process. A senior title should never be a substitute for evidence.

Help desks deserve particular attention. Support personnel are trained to be helpful, and attackers exploit that virtue with plausible personal details, manufactured urgency, or a chain of small requests. Recovery is part of the authentication system.

Strong primary login controls can be undermined by a weak account-recovery path. Support teams need clear escalation rules, resistant verification, meaningful logging, and protection from pressure—not just a script that can be rehearsed by an impersonator.

---

Permissions make the attack bigger

Gaining access is only the beginning. The scale of harm depends on what the identity can do and how long it can do it. Excessive permissions turn a single compromised account into a map of the business. Standing administrator rights, broad shared drives, unrestricted mailbox access and old project memberships all create opportunities for lateral movement and data theft.

Least privilege is often presented as an access-control principle, but it is better understood as blast-radius management. Give an identity only what it needs, only for as long as it needs it, with sensitive actions requiring additional context.

Use just-in-time elevation for administration. Separate approval from execution. Review dormant accounts and entitlements. Make access recertification meaningful by showing owners what a permission enables, rather than asking them to approve a list of opaque group names.

Strong least-privilege security limits the damage that can follow an account takeover and prevents one compromised identity from becoming a universal key.

OAuth introduces a particularly subtle form of delegated trust. A user may consent to an application that does not need their password at all. The app then receives scopes that can read mail, modify files, send messages or act continuously through a refresh token.

An approved application can therefore become a durable, invisible employee in the tenant.

Organizations should maintain an inventory of OAuth applications, restrict high-risk consent, require administrator approval for sensitive scopes, monitor unusual grant activity, and remove unused applications and tokens. This is an important part of OAuth security and modern identity governance.

The question is not simply "Was consent given?" It is "Was the scope necessary, expected, and still justified?"

---

The identities that do not belong to people

Human accounts receive most of the attention, while machine identities quietly multiply. Service accounts, workload identities, API keys, certificates, bots, robotic processes and integration accounts often have long lives, broad permissions and weak ownership.

They do not tire, change jobs or report suspicious prompts. They also do not necessarily fit neatly into a conventional MFA program.

A compromised service account can look like routine automation. Its activity may be spread across many systems, making a sudden login from a new country less useful as a signal.

The answer is disciplined machine identity security and identity lifecycle management: name an owner, record the purpose, constrain permissions, rotate secrets, prefer short-lived credentials, bind workloads to their expected environment, and alert when behaviour departs from that purpose.

Dormant and orphaned identities should be removed, not merely documented.

AI agents make this imperative more urgent. An agent connected to mail, customer records, code repositories, or financial workflows can take actions at machine speed, often using delegated permissions.

The issue is not whether an agent is "trusted" in the abstract. It is whether its tools, data boundaries, instructions, and approval requirements are explicit.

Treat an AI agent as an identity with a capability budget. Limit which systems it can call, which data it can retrieve, and which actions it can perform without a human checkpoint.

Log its prompts, tool calls and outputs where appropriate, protect its credentials, and design for immediate revocation.

An agent that can draft a payment is materially different from one that can submit it. AI agent security must therefore include clear permissions, monitoring and an immediate emergency stop.

Automation should reduce risk, not hide it behind a friendly interface.

---

Vendors turn trust into a supply chain

A business can secure its own tenant and still inherit risk from a supplier, consultancy, software provider or managed service team.

Third parties may hold privileged accounts, connect through federation, operate remote-management tools or process sensitive information. Their access is often necessary; its invisibility is not.

Supplier assurance should move beyond questionnaires. Map the identities and connections that cross organizational boundaries. Require named ownership, strong authentication, time-bounded access and prompt offboarding.

Monitor vendor sessions as carefully as employee sessions, and ensure contracts support timely incident notification and usable audit data.

Where feasible, isolate administrative pathways and provide access only to the systems relevant to the engagement.

This is a critical component of third-party identity security. Trust should be earned continuously. A supplier's reputation, contract, or familiar logo cannot substitute for controls around the actual account and connection.

The same principle applies inside the enterprise: a trusted department can still have an over-privileged, compromised identity.

---

A practical framework: verify, constrain, observe, recover

A durable identity security program can be organized around four mutually reinforcing habits.

1. Verify the person, device and purpose

Deploy phishing-resistant MFA for priority populations and applications, then expand it. Strengthen recovery and help-desk verification.

Establish device health requirements for sensitive access. Tie unusual actions to step-up approval, not merely unusual logins.

Ask whether the requested access makes sense for this person, this device, this time and this business purpose.

2. Constrain every identity

Apply least privilege to people, services, vendors, and AI agents. Prefer short-lived credentials and just-in-time access.

Separate duties for payments, identity administration, and data export. Restrict OAuth consent and high-risk scopes.

Segment sensitive systems so that one stolen identity cannot become a universal key.

3. Observe behaviour and relationships

Centralize useful identity, endpoint, SaaS, and application signals. Build a baseline for normal access without assuming that "normal" means safe.

Detect new authentication methods, suspicious forwarding rules, unusual downloads, abnormal token use, impossible travel combined with sensitive activity, unexpected service-account behaviour, and new third-party grants.

This continuous identity threat detection and response (ITDR) approach helps security teams connect signals that may appear harmless when viewed independently.

Make alerts actionable: show the identity, resource, action, context and likely business impact.

4. Recover decisively

Prepare playbooks for account takeover, session theft, OAuth abuse, infostealer infection, vendor compromise and deepfake-enabled fraud.

Practice revoking sessions, resetting credentials, removing malicious grants, disabling forwarding rules, isolating devices, and contacting affected suppliers.

Preserve evidence while restoring safe work. Recovery should be fast enough that teams do not invent unsafe workarounds under pressure.

This framework is not a product category or a promise of perfect detection. It is an operating discipline. Its measure is not how many controls an organization owns, but how quickly it can reduce an identity's opportunity to cause harm.

---

What should leaders ask now?

Boards and executive teams do not need to become identity engineers, but they do need a clear view of identity risk.

Useful questions include:

• Which identities—human, machine, vendor and AI—can reach our most consequential systems?
• Where do we still rely on passwords, push approvals or weak recovery processes for privileged access?
• Can we revoke a compromised session and third-party grant quickly, and can we prove that we did?
• What would an attacker be able to do with a finance user's mailbox, a developer's token or a service account?
• How many standing privileges and dormant identities remain, and who owns them?
• Which supplier connections are persistent, and how are their sessions monitored?
• Are high-impact requests independently verified when they arrive through email, voice or video?
• What actions can our AI agents take without human approval, and how would we stop them immediately?
• Do our exercises test identity compromise and trusted-workflow abuse, or only perimeter intrusion?

The answers should be specific enough to drive investment and accountability.

"We have MFA" is a control statement.

"All administrators use phishing-resistant authentication, recovery is independently verified, privileged access is time-bound, and sessions can be revoked centrally" is an assurance statement.

---

The work ahead

The shift from perimeter defense to identity defense does not make networks, endpoints, or application security less important. It connects them.

A suspicious login may only become meaningful when paired with an unhealthy device, an unfamiliar token, a new OAuth grant, and an unusual data action.

Effective security programs bring these signals together while respecting privacy, avoiding unnecessary surveillance and giving analysts the context to act.

There is also a cultural shift to make. Security should not be the department that says "no" to every new workflow, nor should convenience make trust invisible.

Productive friction belongs at the moments where mistakes are expensive: changing a payment destination, granting broad application access, elevating privileges, exporting sensitive data, or allowing an automated agent to act externally.

The strongest organizations make the safe path the easy path. They provide passwordless sign-in rather than asking users to defeat increasingly clever phishing. They make verification procedures practical, not heroic. They give managers understandable access reviews. They design automation with boundaries and an emergency stop. Strong Malware Protection also helps ensure that trusted identities and approved applications cannot become easy routes for malicious activity.

They measure containment, not just prevention. Effective Ransomware Detection enables organizations to identify suspicious activity early, while Ransomware Protection helps limit the impact before an incident becomes a wider business crisis.

The next hacker will not always look like an intruder. They may look like an employee on a familiar laptop, a supplier's administrator, a helpful support caller, an approved application or an automated agent doing exactly what its permissions allow.

That is why identity security must be treated as a living security boundary rather than a directory of usernames.

---