Carriers added that question to renewal forms because ransomware operators worked out that the fastest way to force a payout is to wipe the backups first and encrypt everything else after. CISA, the FBI, and the Internet Crime Complaint Center have all documented this pattern as one of the most common moves in current ransomware playbooks. A business whose backup copies can be deleted using the same admin credentials an attacker just stole has no recovery path other than paying the ransom.

This post covers what immutable backup means, three common backup setups that do not qualify, the questions to send your IT provider before you sign the form, and what to do if your honest answer is no.

Immutable backup, defined

An immutable backup is one that cannot be modified or deleted for a fixed period of time, including by you, by your IT provider, and by anyone using stolen admin credentials.

The stolen credentials piece is what carriers care about. Most backup systems can be wiped by anyone with admin access. Immutability means the backup platform itself enforces the lock at the storage layer, and no credentials, however privileged, can override it during the retention window. Some platforms call this object lock, write-once-read-many, or WORM storage. The terminology varies between vendors, but the underlying control is the same.

Three common backup setups that do not qualify

Three setups come up regularly that don’t satisfy the immutability question, even though business owners often assume they do.

A NAS or external drive in your office

A network-attached storage device sitting in your server room is reachable from your network by design. If ransomware spreads across your environment, it can reach the NAS. An attacker with domain admin credentials can wipe what’s on it. An external drive that someone plugs in once a week and leaves connected has the same exposure.

These devices have a role in a broader backup strategy. On their own, they do not satisfy the immutability question.

Microsoft 365 retention treated as a backup

Microsoft 365 includes data retention features, and some businesses use them as their backup solution. They are not a backup in the sense the form is asking about. An attacker with global admin access to your tenant can delete data and purge retention holds.

Under Microsoft’s shared responsibility model, customers retain responsibility for backup and protection of their own data, separate from what Microsoft provides at the platform level.

If your only protection for Microsoft 365 data is what Microsoft provides natively, the honest answer to the immutability question is no.

A cloud backup with immutability switched off

This is the most common gap. Many reputable backup platforms include immutability as a feature, but the setting is not always enabled by default. The capability exists, and someone needs to turn it on. Your business may be paying for a backup solution that looks credible on paper while the immutability toggle sits in the off position. You cannot tell from the outside without checking.

Three questions to send your IT provider before you sign the form

Copy these into an email and send them before you check the box.

Question one: “Are our backups immutable, and if so, how long is the immutability window?”

Carrier guidance has tightened in the past two years. Most insurers want a window of at least 14 days as a floor, with 30 days increasingly cited as the preferred minimum. Attackers sometimes sit in a network for weeks before triggering ransomware, which means a backup from yesterday may already be compromised. The window needs to be long enough to give you clean restore points from before the attacker arrived.

Question two: “If our domain admin account or Microsoft 365 global admin account were stolen tomorrow, could that account be used to delete our backups?”

The correct answer is no. If the answer is yes, or if your provider is not sure, your backups are not immutable in the way the form means.

Question three: “Can you send me a screenshot or vendor documentation showing that immutability is enabled on our account?”

A provider who can send something concrete has done the work. If they come back with verbal reassurance and nothing to show, treat that as a no until they can demonstrate otherwise.

What a qualifying setup looks like

For your backup to honestly satisfy the question on the form, a few things need to be true at the same time.

The backup platform needs immutability turned on, not only available as a feature. Several major vendors including Veeam, Datto, Rubrik, and Acronis offer the capability, along with most cloud storage providers that support S3-compatible object lock. A vendor name on the invoice does not, by itself, answer the question. The setting has to be turned on, scoped properly, and tied to credentials that aren’t shared with the rest of your environment.

The backup credentials need to sit outside your regular administrative accounts. If the same login that manages your Microsoft 365 environment also controls your backup platform, a compromised admin account can reach both. A qualifying setup uses isolated credentials outside your day-to-day identity environment.

The retention window needs to be long enough. A 24-hour backup that overwrites itself daily does not help if an attacker has been in your environment for a week. CISA’s #StopRansomware Guide lists immutable, tested backups as a baseline control, and most insurers now align with that position.

Restores also need to be tested. A backup nobody has tried to restore in the past 12 months is not something you can rely on when it matters. Most carriers now ask for the date of your last successful restore test, and they want to see one.

What to do if your honest answer is no

Declare what you have on the form, and use the renewal process as the reason to fix what isn’t there.

The first step is to ask your IT provider whether immutability can be enabled on your existing platform. In many cases the platform already supports it, and turning it on is a configuration change rather than a new product purchase. If the platform supports it and nobody has switched it on, that conversation can usually be resolved in a few days.

If your provider does not know what you’re asking, or cannot give a clear answer to the three questions above, that response is itself important information. This area needs attention before your next renewal date, even if other parts of your IT setup are handled well.

One thing to avoid: do not check yes on the form to dodge a premium hike. Cyber insurance applications function as warranty documents. If a forensic investigation after a claim finds your backups did not match what you declared, the carrier can rescind the policy. Coverage is then treated as if it never existed, and any prior payouts under the same policy term can be clawed back. Misrepresentation discovered after a claim is one of the most expensive mistakes a small business can make on an insurance form.

Checking no on the form will likely cost you something at renewal, either in premium or in coverage terms. That’s a known cost, and it’s manageable. Take the hit on the application, and use the months between now and your next renewal to close the gap.

Frequently asked questions

What does immutable backup mean in plain English?

A backup that nobody can change or delete for a set period of time, even with administrator credentials. The storage platform enforces the lock at the system level, so user permissions cannot override it.

Is Microsoft 365’s built-in retention a backup?

No. Native retention can be bypassed by a global admin or by anyone who steals one. Microsoft’s shared responsibility model places backup of your data on the customer, separate from retention.

How long should the immutability window be?

Most insurers and security frameworks point to a minimum of 14 days. 30 days is increasingly the preferred floor, and some carriers want longer. A longer window gives you more confident recovery if an attacker has been inside your environment for an extended period.

Can my IT provider just turn immutability on?

Often, yes. If your backup platform supports the feature and it has not been enabled, this is a configuration change rather than a new purchase. Ask for written confirmation once it’s done.

What happens if I check yes on the form when I shouldn’t?

The carrier can rescind the policy after a claim, which voids coverage retroactively. Any prior payouts under the same policy term can also be clawed back. Misrepresentation is one of the most common reasons cyber claims are denied.

Sources and further reading

• CISA #StopRansomware Guide — federal guidance on ransomware prevention, including backup and immutability recommendations.
• Microsoft shared responsibility model — Microsoft’s own documentation on which protections sit with the platform and which sit with the customer.
• FBI Internet Crime Complaint Center: Ransomware — current FBI guidance on ransomware threats and recommended controls.

If you’re not sure where your backups stand, that’s worth raising with your IT provider before your next renewal date. They should be able to walk you through the configuration and give you a clear answer to the three questions above. And if you don’t have an IT provider, feel free to reach out to us and we’ll help you sort it.

—

Featured Image Credit

This Article has been Republished with Permission from The Technology Press.

The post What Immutable Backup Means on Your Cyber Insurance Form appeared first on SpeedWise IT Services.

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. But 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, break 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, not 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, 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, not 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, making 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: 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.

—

Featured Image Credit

This Article has been Republished with Permission from The Technology Press.

The post Why Human Habits Are Your Biggest Security Risk appeared first on SpeedWise IT Services.

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: a form of phishing-resistant authentication that uses your device’s built-in security instead of a shared secret. 

It is practical, 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, 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. But 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. And 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, 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: 

1. Which platforms already support passkeys
2. Which users to start with
3. 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.

—

Featured Image Credit

This Article has been Republished with Permission from The Technology Press.

The post What is Passkey Migration and How Can It Help Your Team Eliminate Passwords? appeared first on SpeedWise IT Services.

What nobody checks is their login to the project management tool they signed up for in Q3, the cloud storage folder they shared with a contractor, or the CRM access they still have from two roles ago. 

Three months later, those sessions are still active.

This is how zombie accounts form. nNot through negligence, but through an offboarding process built around corporate IT assets that no longer reflects how people actually use software. 

The average company now runs more than 100 SaaS applications. Most offboarding checklists were written when there were three.

What a Zombie Account Actually Is

A zombie account is an active login that belongs to someone who no longer works for you. The name is informal. The risk is not.

What makes zombie accounts particularly dangerous is that they are valid credentials.

There is nothing to detect. The access was granted intentionally, and the system has no reason to question it. If a former employee walks back in through that door, or if their credentials are compromised after they leave, the access is there waiting.

Industry research finds that 50% of organizations have discovered former employees still accessing SaaS applications months after their departure date.

For most of those organizations, the discovery was accidental rather than the result of a deliberate audit.

The Three Apps Where Access Never Gets Removed

Cloud storage and collaboration tools

Google Drive, OneDrive, and Dropbox are where zombie access causes the most immediate damage. 

These platforms are where offboarding gets messy. Files may be shared with a departing employee’s personal account. Guest permissions granted during a project may never get cleaned up. And folders set to “anyone with the link” access may still be bookmarked.

The departure triggers a license removal in the identity provider. The shared folders, external links, and personal-account shares go untouched.

Project management and CRM platforms

Tools like Asana, Monday.com, Notion, Jira, HubSpot, and Salesforce are frequently provisioned by team leads rather than IT. That means the offboarding checklist has no visibility into them. 

A former account executive’s Salesforce login, or a project manager’s Notion workspace with access to company strategy documents, can persist for months without anyone noticing.

The tools IT didn’t know existed

This is the most dangerous category. 

These are the tools employees signed up for using their work email. A survey platform. An AI writing assistant. A data visualisation tool. They were never formally provisioned, and they were never formally revoked.

When the employee leaves, the account does not get disabled. It sits there, attached to a work email address that may now redirect to an IT catch-all.

Running the Zombie SaaS Audit

Step 1: Build your SaaS inventory

Start by pulling a list of all SaaS applications connected to your identity provider: Microsoft Entra ID, Google Workspace Admin, or Okta, if you use one. 

Cross-reference with billing records, browser extension installs, and email domains showing regular login notifications.

Grip Security’s 2025 SaaS Security Risks Report, analyzing 29 million user accounts, identified 23,987 distinct SaaS applications in use across its customer base. That’s far more than any IT team tracks manually.

Of those applications, 90% remained outside IT’s management. 

For smaller teams without a dedicated identity platform, a 30-minute review of active subscriptions and recent login notifications will surface most of the high-risk tools.

Step 2: Cross-reference against your offboarding list

Take the last 12 months of departures and check each name against the SaaS inventory. 

For each application, ask: 

• Does this platform have an admin console? 
• Can you see who is still active? 
• When did this account last log in?

Access that is months old and belongs to someone who has left is a zombie. Flag it for immediate revocation. Document what you find.

Step 3: Revoke, document, and set a review cadence

Remove the access. Record what was found and when. Then use the audit as the baseline for an offboarding checklist that covers more than the corporate email and laptop. 

Going forward, enforce multi-factor authentication on all remaining active accounts and schedule a SaaS access review every quarter. 

That cadence turns a one-time cleanup into a repeatable control.

Making Offboarding a Security Process

Zombie accounts cannot be removed if no one is looking for them. The SaaS offboarding audit is the starting point.

Want to close the gaps in your SaaS offboarding process? 

Contact us or schedule a consultation to run a zombie SaaS audit and build a repeatable process your team can follow on every exit.

—

Featured Image Credit

This Article has been Republished with Permission from The Technology Press.

The post The “Zombie” SaaS Audit: Finding the 3 Apps Your Former Employees Still Access appeared first on SpeedWise IT Services.

Local administrator rights (the ability to install software, modify system settings, and override security controls) are given to end users far more often than the risk warrants. 

The usual reason is efficiency. 

The practical result is the opposite. Machines that drift from baseline, infections that spread before they are caught, and remediation tickets nobody planned for. Revoking local admin rights directly removes the root cause of most of those tickets.

The Admin Rights and Support Ticket Connection

A standard user account limits what software can be installed, what system settings can be changed, and what processes can run at an elevated level. These limits are not arbitrary friction. They are the boundary that prevents most common problems from ever reaching the helpdesk.

When users have admin rights, those boundaries disappear. 

Software conflicts arise because no approval step exists to catch the incompatibility. Security tools get disabled because a user decided they were slowing things down. Network settings get modified during attempted self-fixes that go wrong. Each of those actions is a predictable support ticket in waiting.

Admin rights are not the cause of every request in the queue. They are the cause of most of the expensive ones.

What the Security Data Shows

The connection between admin rights and security incidents is well-documented, and the numbers make the operational argument clearly.

From 2015 to 2020, the BeyondTrust Microsoft Vulnerabilities Report found that removing administrative privileges could have mitigated 75% of all Critical Microsoft vulnerabilities.

The pattern holds because most critical vulnerabilities require elevated permissions to fully execute. 

An attacker who compromises a standard user account gets access to that user’s data and session. An attacker who compromises an admin account gets the machine, and often the network.

The IBM Cost of a Data Breach Report 2025 found the average US data breach costs $10.22 million, an all-time high for any region globally.

The remediation cost for breaches that originate through compromised endpoints is consistently higher when the affected user holds elevated system privileges. Revoking local admin rights does not eliminate the risk, but it significantly reduces what an attacker or an infected machine can actually do.

The Three Ticket Categories That Disappear

Malware infections and their cleanup

Most ransomware and many Trojan infections require admin-level permissions to install, disable security tools, and spread. A standard user account does not eliminate phishing risk, but it limits what malware can do after it lands. 

An infection on a standard account is typically contained to that user’s profile. On an admin account, the same infection can encrypt shared drives and require a full OS rebuild. 

A contained malware event might mean one ticket and thirty minutes of work. An admin-level infection often means several tickets and multiple hours of technician time.

Self-inflicted configuration breaks

Users with admin rights occasionally try to fix their own problems by changing settings, uninstalling applications, or modifying network configurations. When it goes wrong, IT inherits the result with little visibility into what changed. 

Standard user accounts remove this category of ticket almost entirely, because those changes are no longer possible without an elevation request.

Patch and compliance drift

Endpoints where users have admin rights tend to diverge from the managed baseline over time. 

Software installed outside the approved process does not receive updates through standard management tools. 

Devices accumulate inconsistencies that create additional work during vulnerability scans, audits, and compliance reviews. 

Revoking admin rights and enforcing managed software deployment closes this drift at the source.

But I Need to Install Things

Just-in-time elevation

The concern is legitimate. As a user on your network, you do occasionally need elevated access for specific tasks. 

The answer is not to restore permanent admin rights. It is just-in-time (JIT) elevation, where you get temporary elevated access for a defined task. The request is approved through an automated policy or by IT, and the elevation expires automatically once the task is complete.

This keeps users productive and IT informed. 

Every elevation request is logged. Unapproved actions do not happen silently. The volume and pattern of requests also becomes useful data in its own right, revealing exactly which tasks genuinely require escalation and which ones users were performing only because nothing was stopping them.

What standard users can already do

Standard accounts support normal application use, browser activity, printing, file access, and the vast majority of day-to-day tasks without any escalation at all. 

The friction you may anticipate is usually larger than the friction you actually experience once the change is made and a JIT process handles the edge cases.

What to Do Before You Flip the Switch

Ready to reduce your support ticket volume and tighten endpoint security for your team at the same time? 

Contact us or schedule a consultation to plan a least-privilege rollout that works for your team.

—

Featured Image Credit

This Article has been Republished with Permission from The Technology Press.

The post Stop the Bleeding: How Revoking Admin Rights Eliminates Support Tickets appeared first on SpeedWise IT Services.

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, in many cases, 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. But AI has changed what AP teams are up against.

 Attacks no longer contain the signals that training programs once focused on: 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, logging 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 have to be complicated. They have 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.

—

Featured Image Credit

This Article has been Republished with Permission from The Technology Press.

The post Is Your Invoice a Deepfake? Securing Your Accounts Payable Process Against Voice and Email Cloning appeared first on SpeedWise IT Services.