Jul 10, 2026
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’s 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’re 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, though, 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, 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, preventing 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’s 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’re 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, not 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’ve 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’s 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, 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, 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’s done badly. Save it for last and budget the time to do it properly.
Frequently asked questions
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, yes, 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.
Sources and further reading
If you’re not sure when your tenant was last reviewed, or whether any of these settings need attention, your IT provider should be able to walk through them with you. 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.
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.
