Jul 5, 2026
Cyber insurance applications include a question that catches a lot of small business owners off guard: “Do you maintain immutable, air-gapped, or offline backups of your critical business data?”
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
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.
Jun 30, 2026
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. 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.
Jun 25, 2026
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: 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:
- 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.
—
Featured Image Credit
This Article has been Republished with Permission from The Technology Press.
Jun 20, 2026
Someone leaves the company on a Friday. By Monday, their email account is disabled, and their laptop is back in the pile.
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.
Jun 15, 2026
The most time-consuming ticket in your queue is rarely a hardware failure. It’s the PC infection that started when a user installed something they shouldn’t have been able to. Or it’s the broken configuration left behind after someone changed a setting IT can’t trace.
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.
