Cybersecurity has spent years getting better at answering one question: is this legitimate? Which it did by asking:
- Is this really the employee trying to sign in?
- Did this email actually come from the domain it claims to?
- Is this an approved device?
- Is this application authorised to access that data?
We’ve built a lot of security around finding those answers. Passwords became multi-factor authentication (MFA). Email authentication became more sophisticated. Identity and access management systems became better at deciding who should be allowed to do what. Single sign-on made it easier to connect those decisions across hundreds of applications.
And attackers noticed. They’re increasingly finding ways to make the answer to that first question yes.
Darktrace described trust as the new attack surface in its August 2026 Mid-Year Threat Update. One of the report’s most interesting findings was that 67 per cent of phishing emails it observed during the first half of 2026 passed Domain-based Message Authentication, Reporting and Conformance (DMARC). Another 39 per cent used novel social engineering techniques.
For anyone who doesn’t spend their days thinking about email protocols, DMARC is one of the mechanisms organisations use to check whether an email is authorised to come from the domain it claims to represent. So there’s an uncomfortable contradiction here. The authentication check can work. And the email can still be malicious.
And the same problem is starting to appear across identity systems, cloud platforms, workplace applications and other parts of enterprise security. Attackers don’t always need to make something fake look real anymore. Sometimes they can compromise something real, abuse a legitimate process or convince somebody to authorise exactly the wrong thing through a system they’ve been trained to trust.
Which means security teams increasingly have two questions to answer. Firstly, is this trusted? And then does what this trusted person, system or service is doing actually make sense? That difference is where the risk starts to get interesting.
Attackers Don't Always Need To Break Trust Anymore
We tend to picture cyber attacks as someone trying to get through a barrier. They the password. Find the vulnerability. Bypass MFA. Infect the device. Exploit a misconfiguration. Somehow, they get from the unsafe outside to the protected inside. Plenty of cyber attacks still work exactly this way.
But what happens when the attacker doesn’t need to break the control at all?
They might steal the credentials belonging to a genuine employee. Take over an existing session. Persuade someone to approve a real MFA request. Communicate through an approved workplace platform. Use legitimate administration software that already has permission to operate inside the organisation.
In each case, the attacker gets closer to looking like normal activity because some of the evidence really is legitimate. That distinction between breaking a security control and satisfying it under false pretences is becoming increasingly important.
CrowdStrike’s 2026 Global Threat Report found that 82 per cent of detections during 2025 were malware-free. Instead of relying on malicious software, adversaries were increasingly using valid credentials, trusted identity flows and approved SaaS integrations as they moved through enterprise environments.
That doesn’t mean malware is disappearing. It doesn’t mean MFA has failed either. The problem is expecting one security control to answer a question it was never designed to answer.
- MFA can tell you that an authentication challenge was completed. It can’t always tell you whether the person completing it understood what they were authorising.
- DMARC can help verify an email’s origin. It can’t tell you whether the person controlling that account intends to steal information.
- A recognised employee account can prove that the correct credentials were presented. It can’t guarantee the employee is still the person controlling the session.
Inside Nvidia's AI Security Push
How an open alliance aims to standardise agent identity, isolation and governance after the Hugging Face breach stress-tested AI defenses.
Those controls are still useful because each one gives the organisation another piece of evidence. The mistake is treating one piece of evidence as the final answer. And attackers are getting very good at finding the gap between the two.
The Signals We Use To Establish Trust Are Becoming Easier To Manipulate
A lot of cybersecurity advice is built around teaching people to notice when something looks wrong. Check the sender address. Make sure the login page is real. Be suspicious of unexpected MFA requests. Don’t give your password to someone who calls claiming to be IT. All good advice.
Unfortunately, the attacks are getting a little more awkward. Some now work because fewer things look obviously wrong.
A real login page doesn't mean a safe login
Device-code phishing may be one of the clearest examples of the problem. Device-code authentication is a legitimate process used when a device can’t easily support a normal login screen. A smart television might show you a code, for example, then ask you to enter it into a website on your phone or computer.
Microsoft investigated an AI-enabled phishing campaign in April 2026 that turned this process against users. The attackers generated valid device codes and eventually directed victims to Microsoft’s official device-login page. If the person wasn’t already signed in, they could go through the normal password and MFA process.
If they were signed in, entering the code and approving the request could authenticate the attacker’s session. The attacker could then receive valid access and refresh tokens without needing to steal the victim’s password. Imagine being the employee on the other side of that interaction. You’ve been told for years to check the website before entering credentials.
Inside Frontier AI Security Gaps
Rogue agents escaping test beds expose weaknesses in current evaluation regimes and raise the bar for how developers harden AI pipelines.
So you check it. It really is Microsoft. You authenticate normally. And you’ve still just helped an attacker into your account. That doesn’t make the advice wrong. It shows why the advice can no longer carry the whole decision. And this isn’t some obscure technique that security teams can safely file under “interesting, but probably not us”.
CrowdStrike recorded a 15-fold increase in monthly device-code phishing attempts during the first half of 2026. The important part isn’t really the device code itself. It’s what the attack tells us. A genuine authentication process can become part of the attack.
A real identity doesn't guarantee a legitimate request
People are part of enterprise authentication too. That’s obvious when you think about password resets, help desks, access approvals and MFA enrolment. Technology performs some of the checks, but people are often the ones deciding whether the situation makes sense.
Attackers can target that decision. Google Threat Intelligence Group and Mandiant documented ShinyHunters-linked activity in January 2026 where attackers impersonated IT staff and called employees claiming that their organisations were updating MFA settings.
Victims were directed to company-branded credential harvesting sites, where attackers captured single sign-on credentials and MFA codes before registering their own devices for continued access. UNC6671, which Google tracks as part of the BlackFile operation, has used a similar strategy.
Callers contacted employees on their personal mobile phones, presented mandatory passkey migrations or MFA updates as the reason for the call, and moved victims through a convincing process designed to establish attacker access. Google says the group had targeted dozens of organisations across North America, Australia and the UK by May 2026.
Nothing about that requires the victim to believe they’re helping a criminal. Quite the opposite. The attack works best when they believe they’re helping IT. And the wider numbers suggest that attackers are finding this useful.
Governing Rogue AI Identities
Lessons from the OpenAI incident on enforcing least privilege, isolating research models and closing gaps in AI access governance.
Mandiant’s M-Trends 2026 report, based on more than 500,000 hours of frontline incident investigations conducted during 2025, found that voice phishing accounted for 11 per cent of observed initial infection vectors. That made it the second most common entry route in its investigations, while traditional email phishing accounted for six per cent.
So the security problem isn’t simply that people can be tricked. We’ve known that for a very long time. It’s that the attacker can recreate enough of a legitimate business process that the victim has fewer obvious reasons to question it.
A trusted channel doesn't guarantee trusted intent
The communication channel can create the same problem. A random message from somebody you’ve never met starts with very little credibility. A Microsoft Teams message from what appears to be a colleague or IT support gets a head start.
Microsoft saw increasing abuse of this familiarity during the second quarter of 2026. Weekly malicious Teams-based voice-call attempts reached almost 10 times the mid-2025 baseline by the end of June, while the company noted that attackers were expanding into workplace communication platforms where messages may appear more trustworthy to users.
Business email compromise (BEC) shows how attackers can build that credibility over time too. Between 87 and 92 per cent of the initial BEC emails Microsoft observed each month during Q2 2026 were generic conversational outreach. Direct requests for documents or specific financial transactions represented just three to eight per cent.
So instead of: “Please transfer £200,000 to this mysterious bank account immediately.” The first message is much more likely to be the digital equivalent of: “Are you at your desk?” Much less dramatic. Also much easier to answer. And that first response starts a conversation.
It gives the attacker an opportunity to establish familiarity before asking for anything risky. By the time the dangerous request arrives, the recipient may no longer be deciding whether they trust a stranger. They’re continuing what already feels like an established interaction.
When AI Agents Inherit Identity
Why CISOs must treat agentic systems as first-class identities, with scoped, short-lived credentials defining AI boundaries across every environment.
Which brings us back to those authenticated phishing emails. Email authentication can give you evidence about provenance. It can’t tell you what the sender plans to do next. The more convincingly attackers can reproduce these familiar signals, the less useful any one of them becomes as proof of safety.
And AI is making that reproduction considerably easier.
AI Is Changing The Economics Of Deception
Social engineering existed long before generative AI. People have always been good at impersonating authority, exploiting urgency and finding creative ways to convince someone that a strange request is perfectly reasonable. The difference is effort. A convincing targeted attack traditionally takes work.
Somebody has to research the victim. Understand their role. Work out which process they might recognise. Write the messages. Adapt the language. Build whatever fake environment supports the story. Do that for one senior executive and the time may be worth it. Doing it convincingly for thousands of people is harder.
AI changes the calculation. Microsoft found generative AI being used to create hyper-personalised lures in the device-code campaign it investigated. Messages were adapted to victims’ roles, with themes including invoices, requests for proposals and manufacturing workflows.
The attackers also used automation for dynamic code generation, reconnaissance and parts of the post-compromise process. This is where the discussion about AI-powered cyber attacks needs to move beyond “AI writes better phishing emails”. Better writing is useful to an attacker. Scale is much more useful.
The World Economic Forum’s Global Cybersecurity Outlook 2026 found that 87 per cent of respondents identified AI-related vulnerabilities as the fastest-growing cyber risk during 2025. It also found that 77 per cent had seen an increase in cyber-enabled fraud and phishing.
INTERPOL’s Global Financial Fraud Threat Assessment 2026 gives us an idea of why criminals might keep investing in it. The organisation reports that AI-enhanced fraud can be 4.5 times more profitable than traditional methods, while agentic AI can increasingly support activities across the fraud lifecycle, from reconnaissance through to execution.
AI isn’t the only technology making this easier either. In July 2026, Okta Threat Intelligence published research into Work Panel, a commercial platform built to support vishing-driven account takeover operations.
Different users can handle infrastructure, campaign management and the calls themselves. Okta’s analysis showed an increasingly specialised cybercrime operation where the social engineer talking to the victim can effectively become interchangeable labour because the surrounding platform handles so much of the process.
That’s a very different model from the lone attacker painstakingly building every part of a campaign. And it tells us something important about where social engineering may be heading.
AI doesn't create the human tendency to trust familiar people, processes and environments. It makes those signals cheaper to reproduce convincingly and at scale. Once convincing legitimacy becomes easier to manufacture, enterprises need a better way to decide how much confidence each signal deserves.
Authentication Is Evidence Of Trust, Not Proof Of Safety
It would be easy to reach the wrong conclusion from all of this. If attackers can abuse MFA, should enterprises stop relying on MFA? Obviously not. The same applies to email authentication, single sign-on, passkeys, identity proofing and software signing. Stronger authentication remains an essential part of modern cybersecurity.
The problem is binary trust.
- Authenticated. Therefore safe.
- Known account. Therefore safe.
- Approved service. Therefore safe.
- Real website. Therefore safe.
Security controls rarely make claims that broad. Organisations make them broad when they allow one successful check to stand in for everything that follows.
Different trust signals establish different things.
| Trust Signal | What It Can Establish | What It Can't Establish Alone |
| MFA completed | An authentication challenge succeeded | The user understood what they authorised |
| DMARC passed | Email authentication checks succeeded | The message is safe |
| Valid employee account | A recognised identity authenticated | The legitimate employee controls the session |
| Trusted SaaS platform | Activity came through approved infrastructure | The activity is expected or benign |
| Signed software | Code passed an authenticated signing process | The wider software supply chain is uncompromised |
| AI agent credentials | The agent has authorised access | The requested action is appropriate |
That last column is where a lot of security risk now lives.
And even formal identity standards are adapting to a world where the evidence itself can be manipulated.
The National Institute of Standards and Technology’s current digital identity guidance recommends that credential service providers introduce ways to detect forged or manipulated media during remote identity proofing. It also recommends analysing digital media for signs of known generative AI and deepfake tools, and using measures such as device attestation to increase confidence in where that evidence came from.
There’s something almost circular about that. An organisation asks for evidence to prove an identity. Then it needs more evidence to establish that the first piece of evidence is genuine. But this is probably closer to how digital trust needs to work now. Not one perfect proof. Several pieces of evidence, considered together, with stronger verification when the consequences of being wrong are higher.
Because enterprises can’t simply stop trusting things. Nobody is going to run a multinational company where every employee, system and application is treated like a suspected criminal every time it tries to do something. Work would grind to a halt before lunch.
The better question is how much evidence should be required before a particular action deserves trust. And authentication only answers part of that.
Enterprise Security Needs To Verify Behaviour, Not Just Identity
Knowing who performed an action is useful. But once attackers can operate through legitimate accounts, knowing who is increasingly only the beginning. Security teams also need to understand what that identity is doing.
- Is this normal for them?
- Are they accessing something they rarely use?
- Did they suddenly register a new authentication method?
- Are they downloading far more data than usual?
- Did the request come from an unfamiliar location or device?
- What happened immediately before it?
- Does the action fit the person’s role?
- And, perhaps most importantly, what happens if the organisation gets this decision wrong?
This is why Mandiant’s 2026 recommendations include moving towards continuous identity verification and behavioural anomaly detection rather than relying entirely on traditional MFA and static indicators. The idea sounds technical, but the underlying logic is simple.
Identity tells you who somebody appears to be. Behaviour gives you another way to decide whether what they’re doing makes sense.
What evidence are we actually trusting?
Before organisations can strengthen their trust decisions, they need to know where those decisions are already being made. And there are probably more of them than anyone thinks.
An email arrives from an authenticated domain. A known device connects. A corporate account requests a file. An executive approves a payment. An internal Teams message asks an employee to do something. A SaaS platform requests access through an existing integration.
None of those things is inherently risky. The useful question is what happens because the organisation accepts them. Imagine an authenticated email from the finance director is enough to start changing supplier payment details. In that case, the email isn’t only carrying information. It’s carrying business authority.
Or perhaps a service desk can reset an administrator’s account after a caller provides a handful of personal details. Those identity checks are doing more than confirming information too. They’re deciding whether somebody gets privileged access. Once you start looking at trust this way, the goal isn’t to catalogue every login and email.
It’s to identify where one familiar signal can unlock a disproportionately important action.
What happens when that evidence is genuine but compromised?
There’s a useful question security teams can ask when designing those processes: If the attacker passed this control legitimately, what would stop the next action?
Assume they have the correct username and password. That MFA succeeds. They’re operating through the approved SaaS platform. And the message really does come from an internal account.
Then what? That question changes the way you think about defence. Maybe the next safeguard is behavioural analytics that notices the employee has never downloaded thousands of files before.
Perhaps a major bank-detail change requires confirmation through a different communication channel. A privileged account reset might need stronger identity proofing than an ordinary password reset. A sensitive data export could require approval from somebody else. Least-privilege access can reduce what a compromised account is able to reach in the first place.
None of these controls is the universal answer. They work because they add more context at the point where getting the decision wrong becomes expensive.
Which trust decisions carry the greatest consequences?
There’s an obvious danger in taking this too far. If every routine action triggers three authentication prompts, an approval workflow and a phone call from security, employees won’t become wonderfully security-conscious. They’ll become annoyed.
And annoyed people get very creative about finding shortcuts around processes that make their jobs unnecessarily difficult. So continuous verification shouldn't mean maximum friction everywhere. It should mean matching the strength of verification to the risk of the action.
A routine low-risk request may need very little extra scrutiny. But organisations may want stronger contextual checks around things like:
- Privilege changes and administrator access
- Financial transfers or payment-detail changes
- Credential resets and account recovery
- New devices, MFA methods or passkey registrations
- Large exports of sensitive information
- Software releases
- Access to critical business systems
- High-impact actions performed autonomously by AI
This is where risk-based security becomes more useful than simply adding another authentication step. The organisation isn’t asking every action to prove itself equally. It’s reserving stronger evidence for the decisions where misplaced trust could cause the most damage.
That approach becomes even more important as a new type of identity starts doing more work inside enterprise systems — namely AI agents.
AI Agents Will Make Trust Infrastructure Even More Important
For most of enterprise computing history, identity and authentication have been designed around a fairly understandable split. People use systems. Systems perform predefined actions. AI agents make that separation much less tidy.
An agent can access files, query databases, call application programming interfaces (APIs), communicate with SaaS platforms, use credentials and trigger workflows. Some can make decisions and take actions on behalf of a person without waiting for approval at every step. That can make them incredibly useful.
It also means they need authority. Darktrace recorded a 13 per cent increase in AI service connections per deployment during the first half of 2026. Across its customer base, those connections exceeded 16 million, while the typical organisation was interacting with seven different AI providers.
As those systems become more connected to enterprise environments, AI agent security raises a slightly different version of the trust problem we’ve already been looking at. What happens when the identity is legitimate, the access is authorised and the action is still wrong?
Okta Threat Intelligence demonstrated the problem in April 2026. Researchers gave an AI agent access to credentials and exposed it to a mock website containing a simple form asking for an email address. The agent ended up revealing its credential store, including an email address, password, API key and GitHub personal access token.
Nobody had stolen the agent’s identity. Nobody had necessarily broken the access control. The agent had permission to use those credentials. The problem was what influenced the agent to use its legitimate authority in the wrong way. That creates a distinction enterprises are going to need to become very comfortable with:
Authorised machine activity isn't automatically authorised business intent.
An agent may genuinely have permission to read a customer database. That doesn’t mean every request which causes it to query that database should be trusted. It may be allowed to send an email. That doesn’t mean every instruction telling it to send one reflects what the business intended.
So the same security thinking applied to human identities starts extending to non-human identities too.
- Who or what is taking the action?
- What authority does it have?
- Where did the instruction come from?
- Does the action fit its purpose?
- And does the consequence justify another layer of verification before it proceeds?
The more authority enterprises give autonomous systems, the more important those questions become.
Trust Needs To Be Treated As Security Infrastructure
Trust can sound like a very human idea. In enterprise technology, it’s surprisingly mechanical. Organisations are constantly deciding whether an identity, request, message, device, application or action deserves permission to proceed. They make those decisions using trust infrastructure.
That infrastructure includes identity proofing, authentication, authorisation, provenance, behavioural context, verification processes, security telemetry, escalation paths and, sometimes, somebody using their judgement when the automated checks don’t tell the whole story.
None of those mechanisms is enough by itself. They work together. And that may be the most useful way to think about the change happening in enterprise security now. For years, the question has often been: Can we authenticate this?
Increasingly, the more useful question may be: What evidence do we need before we're willing to trust this action?
That sounds like a subtle change. Operationally, it can affect everything from account recovery and payment approvals to SaaS access, security monitoring and AI identity. It also helps avoid the other extreme. The goal isn't to distrust every employee, device and application. It's to stop letting one familiar signal carry more confidence than it deserves.
An authenticated email can remain useful evidence. A successful MFA challenge can remain useful evidence. A known employee account can remain useful evidence. They simply become parts of a decision instead of shortcuts to one. From there, organisations can apply a fairly practical rule:
The greater the consequence of misplaced trust, the stronger and more contextual the verification should be.
That gives security teams somewhere useful to start. Not by asking how to verify everything more aggressively. By finding the decisions where being wrong would hurt most.
Final Thoughts: Trust Still Needs To Be Earned After Authentication
An authenticated email can be malicious. A real employee account can be compromised. Someone can complete MFA and authorise the wrong session. An AI agent can have legitimate access and still follow an instruction the organisation never intended it to follow. None of this means authentication has stopped working.
It means we're asking authentication to carry more meaning than it can reliably provide on its own. And that distinction becomes increasingly important as attackers get better at recreating the evidence people and systems have learned to associate with legitimacy.
Trust becomes an attack surface when attackers can manipulate or reproduce the evidence an organisation uses to decide something is safe enough to proceed.
The answer isn't to remove trust from enterprise systems. That wouldn't be practical, and it probably wouldn't be desirable either. It is to make trust more contextual. More proportionate to the consequence of getting the decision wrong. And capable of changing when the behaviour no longer fits what the organisation originally trusted.
Darktrace's description of trust as an attack surface is useful partly because it connects several security problems that can otherwise look unrelated. Phishing, identity takeover, SaaS compromise, authentication abuse and AI-agent risk may use very different techniques, but many rely on the same assumption.
If something looks legitimate enough, somebody or something will eventually let it proceed. As people, applications and increasingly autonomous AI systems act through the same enterprise environments, knowing who or what has permission will remain essential. Knowing when that permission still deserves trust may become the harder problem.
EM360Tech will continue following how identity, AI and cybersecurity are changing the evidence enterprises can safely rely on, and what security leaders are doing as the line between authenticated and trustworthy becomes harder to draw.
Comments ( 0 )