Article Summary: Microsoft 365 Copilot retrieves files, emails and chats using each user's existing Microsoft 365 permissions. In most tenants, those permissions are broader than anyone has mapped because access accumulates across years of projects and staff changes. A safe Copilot rollout begins with auditing those permissions, fixing the gaps and applying sensitivity labels to confidential content. Microsoft publishes specific guidance on this cleanup structured into a pilot, deploy and operate sequence.
A safe Microsoft Copilot rollout starts with a permissions audit before any trial license is enabled. Microsoft 365 Copilot retrieves files, emails and chats using each user's existing Microsoft 365 permissions. In most tenants, those permissions are broader than anyone has mapped because access tends to accumulate across years of projects, ad-hoc sharing and staff changes. Microsoft itself now recommends a specific cleanup before any trial. Map who currently has access to what, fix the permissions that have drifted out of scope and apply sensitivity labels to confidential content.
This post covers what Microsoft 365 Copilot does with permissions, where oversharing tends to show up in a typical tenant, the kinds of content Copilot can return when permissions are broad, how to run the audit Microsoft recommends and what to fix before any rollout.
How Microsoft 365 Copilot Accesses Your Data
Copilot answers questions and generates content by retrieving information through Microsoft Graph which is the API layer that ties together your Microsoft 365 services. When a user asks Copilot a question, it pulls from emails, calendar items, SharePoint documents, OneDrive files, Teams messages and meeting transcripts that the signed-in user has permission to access.
The critical phrase in Microsoft's own documentation is short. Copilot can only summarize or reference content that the user is authorized to access.
That statement is accurate and it is also where the risk sits. The variable is whether each user's permission set still matches what you assume it covers.
Why Permissions Tend to be Broader Than Anyone Thinks
For a manufacturer or trades business, most of the data sitting in your Microsoft 365 tenant is operational. Inventory records, production schedules, supplier contracts and project files. Some of it is sensitive but the consequences are usually contained when the wrong employee reads a document.
At a professional services firm, the dynamic is different. The files are the product itself. Client matters, settlement figures, fee arrangements, deal terms, financial data and employment records make up the deliverable and the confidentiality of that material is the whole business model. Yet the same files often live in environments that were never properly scoped.
The reason is structural. “Just give them access for the Henderson matter” is how it starts. The matter closes, the access is never removed and eighteen months later that person has read permissions on a folder they have no current reason to be in. Multiply that across five years of staff changes, project onboarding, ad-hoc Teams channels and external sharing links that never expired. The result is a permission environment that nobody fully understands.
If the permission exists, Copilot can use it. Whether it was granted with appropriate scope is not part of the calculation.
Microsoft now acknowledges this directly. The company publishes a deployment blueprint for Copilot rollouts that organizes the work around three pillars: remediate oversharing, set up guardrails and meet AI regulatory requirements. Microsoft's own guidance puts oversharing remediation first because it is the pillar that has to be addressed before any rollout produces a useful result.
What Copilot Can Return in a Tenant with Broad Permissions
Five examples of what Copilot can return when broad permissions exist and have not been audited:
“What is everyone's salary?” Returns the compensation spreadsheet HR shared with a hiring manager during a recruitment process eighteen months earlier. The file remained shared after the hiring manager got promoted.
“Summarize the [client] case.” Pulls content from a SharePoint site set up for a different team. A user added during a one-off project two years ago still has the permission that was never removed and Copilot returns a summary of the case to them.
“What deals are we currently working on?” Aggregates content from M&A data rooms that were never properly closed, pipeline trackers in personal OneDrives that got shared once for a partner meeting and prospect lists sitting in a Teams channel that grew beyond its original membership. The output is a single consolidated view of the firm's commercial pipeline.
“Find everything mentioning [former employee].” Surfaces the termination memo, the severance calculation, the performance review that preceded the exit and any email threads saved to SharePoint. Material that was never intended to be findable below partner level shows up in one query.
“What is our markup on [client] engagements?” Outputs the internal pricing sheet that was shared during a proposal process so two people could review it. The link was never restricted, the file was never moved and the numbers come back when Copilot is asked.
The question of who would ask any of these queries is separate from the question of what Copilot can return. Microsoft's deployment guidance focuses on what Copilot is capable of returning and recommends a permissions review before Copilot is enabled at any scale.
Why a “Small Pilot” is Rarely as Contained as People Think
Running a limited pilot feels like a safe middle ground but the way most firms set them up tends to produce the highest-risk version of the trial.
The three or four people picked for a pilot are almost always senior. Senior staff have the broadest access of anyone in the firm which means any searches they run have the widest possible scope. A pilot with three senior partners produces a higher-risk preview of Copilot than a pilot with three junior staff.
And pilots drift. Licenses get reassigned when a partner decides they are not using one. The person who ends up with the license is often whoever asked most recently which is not the same as whoever has the most appropriate access profile.
Microsoft's audit logs will show you what was asked after the fact but the asking cannot be reversed. Once a Copilot summary has been returned to a user, that information cannot be recalled.
The Cleanup That Should Happen Before Any Trial
Before you click “start trial,” four pieces of work make the difference between a useful test and a disclosure event.
SharePoint sharing audit. SharePoint Advanced Management includes a content management assessment that surfaces permission issues, oversharing patterns and inactive sites. If your tenant has never been reviewed, this is the first place to look. The report identifies which sites are shared more broadly than they should be.
OneDrive external share review. Look at files shared outside the organization that were never recalled. These are particularly common in legal and accounting firms where files get sent to clients for review and then forgotten.
Teams membership review. Confirm that channel membership still reflects who should have access to the files stored there. Channels that grew during an active project and were never trimmed are a frequent source of unintended access.
Sensitivity labels for confidential content. Microsoft Purview sensitivity labels are the mechanism that tells Microsoft 365 which content is confidential. Once applied, you can use Data Loss Prevention policies to exclude labeled items from Copilot processing and use encryption settings that block Copilot from reading the content at all without explicit permission. Without sensitivity labels in place, Copilot has no way to treat a client settlement document differently from a catering invoice.
These four pieces of work generally take four to eight weeks for a firm in the 25-to-100-person range. Some of it can be done by your IT provider. The most sensitive parts (like deciding which document categories deserve which sensitivity label) are best handled with input from the partners or owners who understand the material.
The One Question to Send Your IT Provider
Before you make any decision about Copilot, send this to whoever manages your Microsoft 365 environment:
“Can you show me a report of every file in our tenant that is accessible to more than ten people and flag the ones containing client names, salary figures or financial data?”
If they can produce something useful within a few days, your environment has been managed actively. The report will not be a perfect audit but it will show you the shape of the problem and give you a starting point.
If the answer is “we would need to enable some things first” that itself is informative. It means the SharePoint sharing reports have never been run and the tenant has never been reviewed from a permissions perspective. That is the real answer to your Copilot readiness question and the audit needs to happen before any trial does.
Article FAQs
Does Microsoft 365 Copilot have access to my files by default?
Copilot has access to whatever the signed-in user has access to and it is scoped by Microsoft Graph and existing SharePoint, OneDrive and Exchange permissions. Copilot cannot reach files outside the user's existing permission set.
Can sensitivity labels stop Copilot from reading certain files?
Yes. Microsoft Purview sensitivity labels with encryption can block Copilot from reading the content. Files require the user to have specific usage rights (EXTRACT and VIEW) for Copilot to interact with them. Data Loss Prevention policies can also exclude labeled items from Copilot processing.
Is a small Copilot pilot a safe way to test it?
A pilot is fine if the pilot users have limited access to sensitive content. The common mistake is running a pilot with senior staff who tend to have the broadest access in the firm.
How long does it take to prepare a tenant for Copilot?
For a firm with several years of accumulated content, the preparation usually takes four to eight weeks. The work involves a SharePoint sharing audit, an external share review, a Teams membership review and sensitivity label application.
What does Microsoft say about Copilot oversharing risk?
Microsoft publishes a deployment blueprint that organizes Copilot security work around three pillars: remediating oversharing, setting up guardrails and meeting AI regulatory requirements. The oversharing pillar is the one that should be addressed before any Copilot trial.
Article Summary: Microsoft has tightened several Microsoft 365 defaults over the past few years but those changes do not always apply retroactively. Tenants set up before 2022 or configured by a previous IT provider and left alone since often still have legacy settings in place around file sharing, external email forwarding, third-party app consent, audit log retention and MFA enforcement. Five settings worth verifying.
Microsoft has tightened several default settings in Microsoft 365 over the past few years. Newer tenants get more protection out of the box than tenants set up before 2022 or so. The problem is that legacy configurations stay in place. A setting changed for new tenants in 2024 doesn't retroactively change in yours and historical user consents, inbox rules or sharing links granted before the change are still active.
Here are five settings worth checking in your tenant (especially if it is more than two or three years old, was set up by a previous IT provider or has not been audited in a while).
A few caveats before we start. Some of these settings require Microsoft 365 Business Premium, E3 or E5 licensing to change so if a toggle is grayed out, your license tier is most likely the reason. A couple of these changes will generate support tickets from your team because they change how something already works. None of them need to be flipped all at once.
1. The Default Sharing Link in SharePoint and OneDrive
When someone in your organization shares a file from SharePoint or OneDrive, the link they generate has a default scope. In tenants set up before Microsoft tightened the new-site defaults, that scope is often “anyone with the link” which means anyone who receives the URL can open the file without signing in. No expiration. No record of who else the link was forwarded to.
Newer Teams-created sites now default to “Only people in your organization.” Older sites and the tenant-level setting often still allow Anyone links. A departing employee who emailed a proposal to their personal account six months ago still has a working link unless someone manually revoked it.
The default sharing link type sits in the SharePoint admin center under Policies > Sharing. Switching the tenant default to “Specific people” forces every new link to require authentication. You can also set a maximum expiration for any remaining “Anyone” links so they time out automatically.
Rough time to change: 15 minutes. This has no impact on existing links until they are regenerated.
2. External Email Forwarding Rules
Microsoft now blocks automatic email forwarding to external addresses at the tenant level by default through the outbound spam policy. This rolled out as part of Microsoft's secure-by-default effort.
Forwarding rules created before that change can still be active and tenants with custom outbound spam policies configured years ago may not reflect the current default. A user who set up a rule a few years ago to forward every email to a personal Gmail address may still be exporting your data depending on how their rule was constructed and whether it predates the policy.
Verify two things. In the Microsoft Defender portal, under Email & Collaboration > Policies & Rules > Anti-spam policies > Anti-spam outbound policy, confirm the “Automatic forwarding rules” setting is set to “Off” or “Automatic - System-controlled.” Then audit existing inbox rules across your users for any forward-to-external configurations. The Microsoft Purview audit log lets you search for inbox rule creation events.
Rough time: 10 minutes to verify the tenant setting but longer to review existing rules across all mailboxes.
3. Historical Third-Party App Consents
A Microsoft-managed user consent policy was enabled by default in July 2025 which prevented users from consenting to most third-party applications that request access to their files and sites. New consent requests now route to an admin for review.
The change applies going forward. Apps that were granted user consent before the policy took effect still have whatever permissions they were given including the ability to read mail, calendars and files on behalf of the user. Some of those apps may be tools an employee installed years ago and no longer uses or apps installed during a one-off project that nobody remembers approving.
To review what is already there, go to Microsoft Entra ID > Enterprise Applications > All applications. Sort by user consent and look at what currently has access to mail, files or calendars. Anything you don't recognize or no longer need can be revoked from the same screen.
Rough time: 30 to 60 minutes for the review depending on how many historical apps are in the list.
4. Mailbox and Tenant Audit Log Retention
The default audit log retention period in Microsoft 365 changed in October 2023. Audit (Standard) logs are now retained for 180 days (up from the previous 90 days). Customers with E5 licensing or the Microsoft Purview Audit (Premium) add-on get one year of retention for Exchange, SharePoint, OneDrive and Entra ID audit records with other activity types staying at 180 days.
If you are in healthcare, financial services, legal or any other regulated industry, 180 days may not match your retention obligations. HIPAA, the FTC Safeguards Rule, and most state bar rules around client data assume you can produce records on request and the relevant period is often measured in years rather than months.
Audit retention policies live in the Microsoft Purview compliance portal under Audit > Audit retention policies. Extending retention beyond 180 days requires E5 or the Purview Audit add-on. The configuration itself takes about 15 minutes once you have confirmed your license supports it.
5. MFA Enforcement and Security Defaults
MFA enforcement is the area most likely to be inconsistent in older tenants. Microsoft introduced Security Defaults in late 2019 and the feature now enforces MFA automatically on new tenants. Microsoft has also been progressively making MFA mandatory for admin actions in the Microsoft 365 admin center and Azure portal through 2024 and 2025.
Tenants created before Security Defaults rolled out may have no baseline enforcement. There is also a common configuration trap. When an admin enables a Conditional Access policy which is available with Business Premium and above, Microsoft expects you to take over MFA enforcement through that policy and may turn Security Defaults off. If the transition was done quickly, you can end up with Security Defaults off and a Conditional Access policy that doesn't cover every user.
Check three places. In the Entra ID admin center under Properties > Manage Security Defaults, confirm whether Security Defaults is on or off. Under Protection > Conditional Access, confirm a policy is actively enforcing MFA for all users (including administrators). Pay particular attention to break-glass admin accounts which are sometimes excluded from Conditional Access for emergency access reasons and left with no MFA as a result.
Rough time: About an hour or longer if Conditional Access has been configured with several existing policies you need to map.
A Sensible Order to Roll the Changes
Some of these changes are silent to your users. Others change how something they do every day works.
Audit log retention (#4) and the historical app consent review (#3) carry no user-facing impact. Start there.
Verifying external forwarding (#2) is silent unless someone has a legitimate forwarding rule which is rare. Do this next.
The sharing default (#1) will eventually generate user questions and particularly from anyone used to clicking “share” and pasting the link into an email. Communicate the change before you flip the tenant setting.
The MFA and Conditional Access review (#5) is the highest-stakes change and the one most likely to lock people out if it is done badly. Save it for last and budget the time to do it properly.
Article FAQs
Are my Microsoft 365 settings still vulnerable if my tenant was set up recently?
New tenants get more protection out of the box than tenants set up a few years ago. Even so, certain settings including sharing scope, app consents granted by users and historical inbox rules need to be reviewed in any tenant regardless of age.
What is the current Microsoft 365 default for “Anyone with the link” sharing?
At the tenant level, many existing tenants still permit “Anyone with the link” sharing. Newer Teams-created SharePoint sites default to “Only people in your organization.” Verify both the tenant-level setting and the site-level setting if you want to know what your users see in practice.
Did Microsoft turn off external email forwarding by default?
Yes. Microsoft's outbound spam policy now blocks automatic external forwarding by default at the tenant level. Existing inbox rules created before that change may still be active and worth auditing.
How long are Microsoft 365 audit logs kept by default?
180 days for Audit (Standard) as of October 2023. One year for key workloads (Exchange, SharePoint, OneDrive, Entra ID) if you have E5 or the Microsoft Purview Audit (Premium) add-on.
Does Security Defaults cover all my users?
On a new tenant, including MFA enforcement. On an older tenant that has had Conditional Access policies enabled, Security Defaults may have been turned off and MFA coverage now depends on how Conditional Access has been configured.
Contact us if you need any help with your Microsoft 365 settings.
Article Summary: Personal web habits are one of the least visible cybersecurity risks businesses face when work and personal life share the same devices, browsers and identities. Routine behavior like checking personal email, reusing passwords or signing into familiar apps can expose business data without anyone intending it. The safest approach reduces exposure with clear guardrails, stronger defaults and practical coaching rather than restrictive rules that drive workarounds.
Most cyberattacks do not start with a sophisticated intrusion. They start with a click on a personal email, a reused password or a file uploaded to a familiar cloud service because the approved option felt slower.
The Verizon Data Breach Investigations Report found that 68% of breaches involve the human element.
Not a zero-day exploit. Not a brute-force attack on a hardened system. Human behavior in the course of an ordinary working day.
For businesses running cloud-based workflows across multiple devices, the personal and professional overlap is now the rule. Understanding where that overlap creates risk is no longer optional. It is a core part of modern security strategy.
The Risk Sitting Outside Your Security Stack
Personal web habits are not reckless behavior. They are normal behavior.
Checking a personal inbox on a work laptop. Logging into a social account during a break. Saving a work password in a browser already loaded with personal accounts. Uploading a document to a storage service because it is faster than the approved option.
None of these feel like security decisions in the moment. However, each creates a connection between personal digital activity and business systems and that connection sits outside most traditional security controls.
Hardening systems, deploying tools and locking down networks addresses part of the problem. The rest moves with the people.
How Personal Web Habits Create Business Exposure
Personal channels are phishing’s preferred territory.
Personal inboxes, messaging platforms and social media feeds are where phishing thrives.
These environments are harder to filter, easier to spoof and loaded with the emotional triggers that make people act before they think.
When those channels share a device or browser with business systems, a single click can cross the boundary instantly.
Phishing is the most common entry method for attackers precisely because it exploits distraction rather than technical weakness. The target does not need to be careless. They just need to be busy.
Password reuse turns personal breaches into work incidents.
Password reuse is one of the most direct connections between personal and professional exposure.
When credentials from a personal account are compromised, attackers run them against business systems automatically. This technique (credential stuffing) is low-effort and highly effective because so many people use the same password across multiple accounts.
Unique credentials for every account combined with multi-factor authentication breaks that chain.
A personal breach has nowhere to go when the work account requires a second factor that the attacker cannot relay.
Shadow IT is usually about convenience rather than defiance.
Most unauthorized tool usage does not begin with disregard for IT policy. It begins with a productivity gap. Employees use personal cloud storage, consumer messaging apps or AI tools because they are faster and more familiar than the approved alternative.
The security risk is not the intention behind the choice. It is what happens to the data.
Once business information moves into platforms that IT cannot see, audit or secure, it falls outside every control in place. The tool usage is predictable. The data exposure is not.
Why Blocking Behavior Doesn’t Work
The instinct is to lock things down. Block personal apps, restrict browsing and enforce strict device policies.
In practice, blanket restrictions rarely stop the behavior. They relocate it. Users find workarounds. Unapproved tools move to personal devices. IT teams lose visibility into exactly the activity they were trying to manage.
The risk does not disappear. It moves somewhere harder to see.
Security strategies that assume perfect compliance perform poorly in real workplaces. The goal is not eliminating the overlap between personal and professional digital activity. It is managing it without breaking how people work.
What Actually Reduces Risk
The controls that work are the ones that match how people actually operate.
Separate contexts rather than people.
The simplest way to reduce crossover risk is to reduce crossover.
Separate browser profiles for work and personal activity, clear guidance on where business accounts should be accessed and identity boundaries that prevent accidental mixing all reduce exposure without restricting what people do with their time.
This is not about surveillance. It is about creating enough distance between personal and professional digital activity that a compromise in one does not automatically reach the other.
Design for credential failure.
Assume passwords will eventually be exposed somewhere. Design for that outcome rather than hoping to prevent it.
CISA reports that enabling multi-factor authentication makes accounts 99% less likely to be compromised even when the underlying password has already been stolen.
MFA converts the most common attack path into a dead end.
Stolen credentials from a personal breach cannot reach a work account that requires a second factor. A password manager handles unique credentials across every account which makes that protection sustainable without placing an unrealistic burden on users.
Make secure behavior easier than unsafe behavior.
Personal web habits are not dangerous by default. Ignoring the risk they create is. The most secure environments today are not the most restrictive. They are the most realistic. They are built around how people actually work, designed to contain failure when it happens and focused on making safer behavior the path of least resistance.
Helping clients reduce human-driven security risk is one of the most impactful services an MSP can offer.
Contact us or schedule a consultation to review current controls and identify where the most important gaps are.
Article FAQs
Why do personal web habits increase cybersecurity risk?
These habits often happen outside secure and monitored environments and can expose credentials or data through phishing, password reuse or unapproved tools.
Is blocking personal internet use the best solution?
No. Blocking behavior often leads to workarounds and reduces visibility. Most security experts recommend guardrails, education and separation instead.
How can MSPs reduce risks without hurting productivity?
By enforcing MFA, separating work and personal contexts, providing clear guidance and offering ongoing security education tailored to real workflows.
Article Summary: Passwords remain a leading cause of breaches. However, most teams still rely on them for daily access. Passkey migration replaces passwords over time with device-bound and cryptographic credentials that can’t be phished, reused or stolen from a server. This shift reduces credential risk and helpdesk friction and most teams already have the core infrastructure needed to begin.
Your team locks everything down with passwords. Some are strong, some are not and most have been reused somewhere over the years. Every month, IT fields reset requests. Every year the same breach reports list stolen credentials as the leading cause.
There is now a more effective path and it does not require users to memorize anything.
Passkey migration is the process of moving from traditional passwords to passkeys which is a form of phishing-resistant authentication that uses your device's built-in security instead of a shared secret.
It is practical and it is already supported by most major platforms and the business case is hard to argue with.
Why Passwords Are Still the Biggest Risk
Passwords have had sixty years to prove themselves. The data tells a consistent story.
More than 80% of data breaches involve compromised credentials which is a figure that has remained consistent year after year according to the Verizon Data Breach Investigations Report.
The underlying problem has not changed. Passwords are shared secrets that must be stored somewhere and secrets that get stored eventually get stolen.
Multi-factor authentication (MFA) reduced that risk significantly and remains an important baseline. However, SMS-based codes (still the most common form of MFA) have a known weakness.
Modern phishing kits can intercept a one-time code in real time. A convincing fake login page captures both the password and the code and uses them on the real site before the session expires.
Phishing-resistant authentication closes that gap by design. Passkeys make it technically impossible for a fraudulent page to trigger login on your real device because the credential is cryptographically bound to the legitimate domain.
What a Passkey Actually Is
A passkey is a cryptographic credential. This means that instead of a shared password stored on a server your device creates a matched pair of digital keys when you register with a service.
The private key stays on your device and never leaves it. The public key goes to the service.
When you log in, your device uses biometrics (Face ID, a fingerprint or Windows Hello) or a device PIN to sign a cryptographic challenge from the server. The server verifies the signature using the public key. No password is ever transmitted.
A passkey cannot be phished because a fraudulent login page cannot trigger authentication on your real device. It cannot be reused because it is bound to a specific domain. It cannot be exposed in a server-side breach because the private key never exists outside your device.
Passkeys are built on the FIDO2 (Fast IDentity Online 2) and WebAuthn open standards (backed jointly by Apple, Google and Microsoft). The FIDO Alliance reported that more than 15 billion online accounts now support passkey sign-in which is double the figure from the year before.
What Passkey Migration Actually Means
Passkey migration is not a single cutover. It is a gradual transition that runs passwords and passkeys in parallel until passkeys are established across the accounts and platforms that matter.
A migration plan typically covers three things:
- Which platforms already support passkeys
- Which users to start with
- What fallback options exist for tools that are not yet ready
For most business teams running Microsoft 365 or Google Workspace, the infrastructure is already in place.
Microsoft enabled passkeys through Entra ID and made them the default sign-in for new accounts in May 2025. Google has supported passkeys for Workspace accounts since 2023. For teams in either ecosystem, passkey migration can begin without new infrastructure.
How to Approach Migration Without Disrupting Your Team
Start where support already exists.
Begin with administrators and power users. They reset passwords most often, have the highest-risk access and will give you honest feedback on friction before rollout reaches the wider team.
Map your current tools against passkey support before communicating any change.
Platforms like Microsoft 365, Google Workspace, GitHub, Shopify and most major identity providers already support passkeys fully. Start with those. Leave unsupported tools for a later phase.
Run passwords and passkeys in parallel.
The most common migration mistake is treating it as a full cutover.
Users can authenticate with passkeys on enrolled devices and fall back to a password on any device not yet enrolled. Running both methods simultaneously gives time for adoption without locking anyone out mid-project.
Plan for platforms that are not ready yet.
Not every tool supports passkeys today.
For those, a password manager generating unique credentials is the right bridge. It eliminates the password reuse risk now and when those platforms add passkey support, migration becomes a single enrollment step rather than a behavior change.
The Business Case Beyond Security
Security is the primary driver but the operational benefits are real and measurable.
Google reports that passkey sign-ins are four times more successful than password-based logins with sign-in speeds approximately 20% faster.
According to authentication research published by Google, the improvement comes from removing friction. Users no longer mistype passwords, wait for SMS codes or trigger account lockouts by trying an outdated credential.
Fewer failed logins means fewer helpdesk calls and fewer interruptions.
NIST's 2025 update to SP 800-63-4 now requires phishing-resistant authentication as a mandatory option for high-assurance access. This means passkey migration is also a compliance step for teams working toward those standards.
From Password-Dependent to Passwordless
Ready to start your passkey migration?
Contact us or schedule a consultation to map out which platforms in your environment support passkeys today and build a migration plan that works for your team.
Article FAQs
Do passkeys work across all devices and platforms?
Most modern devices support passkeys natively: iPhone, Android, Windows and Mac all include built-in passkey support through iCloud Keychain, Google Password Manager and Windows Hello. Chrome, Safari and Edge all support passkey sign-in. Not every app or service has added passkey support yet but major platforms including Microsoft 365, Google Workspace, GitHub and Apple ID are fully ready.
What happens if a user loses the device their passkey is stored on?
Passkeys sync across a user's enrolled devices through their cloud keychain. If a device is lost, the passkey is recoverable on any other device signed into the same account ecosystem. Recovery options are configured during enrollment and account recovery flows remain available as a fallback.
Article summary: Conference room device security requires the same attention as any other endpoint: updated firmware, strong credentials and proper network segmentation. Addressing these devices closes a surveillance gap that many businesses do not know they have.Read more
Article summary: When an employee leaves, their old computer often stays on the network forgotten but still connected and completely unmonitored. These ghost devices give attackers an easy entry point into your business because no one is checking them for updates, suspicious activity or lingering access credentials. A proper offboarding and device retirement process backed by ongoing network monitoring closes this gap before it becomes a costly breach. Read more
Article summary: Many small businesses run critical systems that only one person knows how to manage, access or restore. This creates key person dependencies that can bring operations to a halt if that individual is unavailable. Mapping these single points of failure and building redundancy around them is a straightforward business continuity step that most SMBs have never taken.Read more
Article summary: Business owners and executives are the highest-value targets in any organization yet their personal phones, laptops and home computers are often the least secured devices. Executive device security requires the same structured approach applied to employee endpoints. Protecting the gatekeeper protects the entire business.
Read more
Article Summary: AI-enhanced fraud is changing how criminals target finance teams (especially Accounts Payable). Attackers can use AI to produce convincing emails, realistic invoices and even cloned voices that bypass the red flags teams once relied on. The most effective defense combines stronger verification steps, tighter payment processes and a culture where pausing to confirm details is always supported.
It is a statistic that sends a shiver down the backs of SME owners, managers and employees.
According to the FBI's 2025 Internet Crime Report, business email compromise (BEC) cost US businesses more than $3 billion last year.
This makes it one of the most financially damaging cybercrimes on record.
AI has made these attacks harder to detect. The question for AP teams is no longer whether they can identify suspicious requests. It is whether the processes around payments make fraud difficult regardless of how convincing it looks.
Why AP Teams Are in the Crosshairs
Accounts payable sits at the intersection of trust and timing. AP teams process invoices, manage supplier details and execute payments often under pressure to keep operations running smoothly.
For attackers, that combination is ideal.
Most successful fraud does not involve breaking into systems.
The FBI's Internet Crime Complaint Center (IC3) has consistently found that BEC attacks rely on impersonation. This involves posing as a trusted executive, supplier or internal colleague to redirect payments or update bank details before anyone notices.
AI has made that impersonation dramatically more scalable.
Where it once required skill and time to craft a convincing request, tools are now widely available that automate the research, writing and contextual tailoring that make fraud blend into normal AP workflows.
By mid-2024, an estimated 40% of BEC phishing emails were already AI-generated with that share expected to grow significantly.
What AI-Enhanced Fraud Looks Like in Practice
Emails That Blend into Normal Workflow
Traditional phishing relied on volume and imperfection. AI has changed that.
Modern BEC emails are grammatically correct and written in the specific tone of the executive or supplier being impersonated. They reference active projects, current invoice numbers and upcoming payment runs.
For AP teams processing high volumes of routine communications, that level of familiarity is exactly what lowers the guard.
Invoice and Payment Redirection
One of the most common AP fraud patterns involves payment redirection.
Attackers may intercept a legitimate invoice exchange and quietly alter the destination account. They then send a short message claiming a supplier has updated its banking details or re-issue a real invoice with minor modifications.
The surrounding content looks entirely legitimate because it is drawn from real correspondence.
Voice Cloning and Executive Impersonation
Email isn’t the only channel being exploited.
AI voice-cloning tools can replicate a person’s voice from a short audio sample. That makes it possible to leave convincing voicemails or place calls that sound like a known executive.
For AP teams accustomed to verbal approvals on high-value or urgent payments, this removes one of the few remaining verification methods that email security alone cannot address.
Why Traditional Checks No Longer Work
Security awareness training still matters and investing in it remains worthwhile. However, AI has changed what AP teams are up against.
Attacks no longer contain the signals that training programs once focused on like awkward phrasing, mismatched logos, odd sender addresses or generic greetings.
Modern fraud emails can reference the recipient's organization, active suppliers and current invoice values drawn from publicly available or previously intercepted sources.
When a fraudulent request is indistinguishable from a legitimate one, placing the burden of detection on the AP team puts it in the wrong place.
The organizations that reduce risk are not asking staff to be more suspicious. They are building verification processes that work independent of how a message looks.
Building Process Around the Risk
The most effective defense is not sharper instincts. It is removing ambiguity from high-risk actions.
Out-of-band Verification as Standard
Any request to change supplier bank details or approve an urgent payment outside the normal cycle should require secondary confirmation through a known independent channel (not a reply to the same email thread). Calling a supplier on a number already on file or confirming with a colleague directly breaks the impersonation chain regardless of how convincing the original request appeared. This step does not require technology. It requires a written procedure and the team's habit of following it.
Layered Access and Authentication Controls
Restricting access to financial systems and enforcing multi-factor authentication limits the damage a compromised account can cause. If an attacker gains access to a vendor's email, MFA requirements on the receiving end create friction that can slow or stop a fraudulent change before any money moves.
A Culture that Supports Slowing Down
Fraud prevention improves when staff feel safe questioning requests (including from senior leadership).
A team member who pauses a payment to verify it is not being obstructive. They are doing exactly what good process requires.
Building that culture starts with leadership modeling the behavior and making clear that slowing down on high-risk actions is always the right call.
The FBI's 2025 Internet Crime Report included a dedicated AI section for the first time and logged more than $893 million in AI-enabled scam losses across more than 22,000 complaints.
When verification is standard and questioning is encouraged, AI-enhanced fraud loses much of its advantage.
The technology attackers use is advancing quickly but the process controls that contain the damage do not need to be complicated. They need to be consistent.
Shift the Burden from People to Process
Concerned about AI-enhanced fraud targeting your finance teams or clients?
Contact us or schedule a consultation to review your current controls and identify where the most important gaps are.
Article FAQs
Why are Accounts Payable teams targeted so often?
AP teams manage payments and supplier details which makes them a direct path for attackers to move money without breaching technical systems.
Can awareness training alone stop AI-driven fraud?
No. Awareness helps but AI scams often look legitimate. Strong verification processes are essential.
Is voice-based fraud really a risk?
Yes. AI voice cloning allows attackers to impersonate executives convincingly which makes phone-based approvals vulnerable.
Article Summary: Adversary-in-the-Middle (AiTM) attacks are a modern phishing technique that steals active login sessions instead of just passwords. Understanding how AiTM works helps businesses reduce exposure to phishing-resistant sign-ins, tighter session controls and faster detection of suspicious access.
You click a link, sign in, approve the MFA prompt and get on with your day while completely unaware that someone else just logged into your account at the same moment.
That scenario surprises many businesses and particularly those that rely on multi-factor authentication (MFA) to protect cloud accounts. However, this is exactly how Adversary-in-the-Middle (AiTM) phishing attacks work.
Rather than stealing passwords for later use, these attacks silently hijack an already-authenticated session in real time.
MFA remains a core control and getting it implemented correctly is still a critical first step for any business.
AiTM attacks exploit something MFA was never designed to protect which is the trusted session that exists after authentication has already completed.
Phishing Has Moved Beyond Passwords
Phishing remains the most common starting point for account compromise but the objective has changed.
Traditional phishing collected usernames and passwords. Modern phishing is after something more immediately useful which is the authenticated session itself.
Security researchers have documented a significant shift toward session and token theft where attackers intercept the authentication process as it happens.
Rather than reusing stolen credentials (which MFA typically blocks) they wait until the user successfully completes login and then steal the session token that proves it already occurred.
The technique has matured quickly. Phishing-as-a-Service (PhaaS) platforms now supply ready-made proxy toolkits that let even low-skilled attackers run AiTM campaigns targeting Microsoft 365 and Google Workspace.
How AiTM Attacks Actually Work
The fake login page that isn’t fake.
An AiTM phishing site is not a basic replica of a login page. It is a live reverse proxy.
The attacker’s infrastructure sits between the user and the real authentication service. Every keystroke, redirect and server response flows through the attacker’s system in real time. From the user’s perspective, nothing looks wrong.
The page behaves exactly like the real service with correct branding, working redirects and a functioning MFA prompt. In most cases, the only clue is a slightly altered URL that goes unnoticed on a mobile screen or when someone is under time pressure.
Why doesn't MFA stop it?
This is where many security assumptions fall apart.
MFA protects the moment of authentication but not what comes after it.
Once a user successfully completes MFA, the service issues a session cookie. What this means is that the cookie signals to the application that the user is already verified. From that point, no password or MFA prompt is required. The system trusts the token. Whoever holds the cookie holds the access.
AiTM attacks simply wait for that cookie to be issued and then steal it.
Microsoft tracked a 146% rise in AiTM attacks over the past year as cybercriminals increasingly shift focus to accounts already protected by MFA.
Much of this increase is driven by PhaaS platforms like Evilginx that allow even low-skilled attackers to run convincing reverse-proxy campaigns at scale while targeting major cloud identity providers with minimal setup.
Session Cookies
Session tokens act as bearer credentials. Whoever possesses the token can access the account with no password or MFA challenge required.
Once the cookie is stolen, the attacker imports it into their own browser and immediately resumes the session.
This is a session replay attack. The attacker does not log in. They pick up where the legitimate user left off inside a fully trusted and already-verified session.
What Happens After a Session Is Stolen
The aftermath of an AiTM attack tends to be quiet which is precisely what makes it dangerous.
The attacker is operating inside a legitimate authenticated session. There are no failed MFA attempts, no unusual login alerts and nothing in standard sign-in logs to signal a problem.
Research from Proofpoint shows that attackers who gain access through session hijacking commonly create hidden inbox rules to redirect mail, register additional MFA methods to lock in persistent access, monitor email threads for financial conversations and use the trusted account to launch phishing campaigns against internal colleagues or finance teams.
These follow-on actions are a key reason AiTM attacks are frequently uncovered late after financial fraud, data exposure or wider network compromise has already begun.
Reducing Your Exposure
MFA is still essential. Building strong authentication practices remains the starting baseline but reducing AiTM risk requires controls that extend beyond the login event itself.
Adopt Phishing-Resistant MFA
Methods like FIDO2 hardware keys and passkeys bind authentication to the specific device and the legitimate domain. A proxy in the middle cannot relay them. The process fails if the URL is not the real one.
The Canadian Centre for Cyber Security analyzed over 100 AiTM campaigns targeting Microsoft Entra ID accounts. It found that phishing-resistant MFA consistently blocked session theft where standard MFA methods (including push notifications and one-time passcodes) did not.
Tighten Conditional Access Policies
Detecting AiTM compromise typically means watching for activity after login: new MFA method registrations, inbox rules created outside business hours, access from unfamiliar locations or unusual data activity.
Authentication logs alone will not surface the problem.
Train Users on URL Awareness
Employees who understand that a working MFA prompt on an unfamiliar-looking page still represents a risk are better positioned to pause, check the URL and report before a session is compromised. A brief team walkthrough of what AiTM lures look like in Microsoft 365 contexts can meaningfully reduce exposure.
Stop Protecting Just the Login Screen
MFA is a baseline rather than a finish line. The businesses that reduce AiTM risk are the ones that understand how sessions, tokens and identity trust actually work and they build controls around each layer rather than just the login screen.
Want to review your identity security controls?
Contact us or schedule a consultation to identify the gaps that matter most before an incident does it for you.
Article FAQs
What is an Adversary-in-the-Middle (AiTM) attack?
An AiTM attack is a phishing technique where attackers use a proxy to intercept login sessions in real time which allows them to steal session cookies after authentication completes.
Can AiTM attacks bypass MFA?
Yes but not by breaking MFA. AiTM attacks wait until MFA succeeds and then steal the authenticated session token so no further verification is required.
How can businesses reduce the risk of AiTM attacks?
Using phishing-resistant MFA, tightening conditional access policies, training users and monitoring for unusual session behavior all help reduce exposure.