Our blog

A fake recruiter message is one of the cleanest social engineering tricks around because it doesn’t look like a trick. That’s why LinkedIn recruitment scams work so well inside real businesses. They don’t arrive as malware. They arrive as a normal conversation that nudges someone toward one small action: click this link, open this file, “verify” this detail, move the chat to a different app. A few simple checks, a couple of hard-stop rules, and an easy way to report suspicious outreach can shut these scams down without slowing anyone down. LinkedIn Recruitment Scams LinkedIn recruitment scams artfully blend into normal professional behaviour. The message doesn’t look like a “cyber attack.” It looks like networking, and it borrows credibility from recognisable brands, polished profiles, and familiar hiring language. At platform scale, the volume is also hard to wrap your head around. Rest of World reports that LinkedIn said it “identified and removed 80.6 million fake accounts” at registration from July to December 2024. A LinkedIn spokesperson claimed “over 99%” of the fake accounts they remove are detected proactively before anyone reports them. Even with that level of detection, enough scam activity still leaks through to reach real employees. That’s especially true when scammers tailor their approach to what looks credible in a specific industry and location. The other reason these scams succeed is that they follow a predictable persuasion pattern: urgency, authority, and a quick push to “do the next step.” The FTC describes scammers impersonating well-known companies and then steering targets toward actions that create leverage. These actions include handing over sensitive personal information or sending money for “equipment” or other upfront costs. Once someone is rushed into treating the process as real, the scam doesn’t need to be technically sophisticated. It just needs the victim to keep moving. The Scam Pattern Most Teams Miss 1. A polished approach on LinkedIn The profile looks credible enough, the role sounds plausible, and the message is written in a professional tone. The job post itself may still be oddly generic, though. Amoria Bond notes that fake job postings often “lack details” and lean on broad language to catch as many people as possible. 2. A quick push off-platform The conversation shifts to email, WhatsApp/Telegram, or a “recruitment portal” link. That shift is important because it removes the built-in friction of LinkedIn’s environment and makes it easier to send links, files, and instructions.

3. A credibility wrapper: “assessment”, “interview pack”, or “onboarding”

Airswift flags link/attachment requests and urgency tactics as common red flags. The story is usually something like: “Download this assessment,” “Review these onboarding steps,” or “Log in here to schedule.” Tag Apps Make decisions visible and repeatable by tagging apps. Microsoft explicitly calls tagging apps as sanctioned or unsanctioned an important step, because it lets you filter, track progress, and drive consistent action over time. 4. The pivot: money, sensitive info, or account takeover Scammers impersonate well-known companies and then ask for things legitimate employers typically don’t: payment for “equipment” or early requests for personal information. Another variation is more subtle: “verification” steps that are really designed to steal identity details or compromise accounts. 5. Pressure to keep moving If someone hesitates, the scam leans on urgency: “limited slots,” “fast-track hiring,” “complete this today.” That’s why Forbes frames the key skill as slowing down and checking details, because the scam depends on momentum. Red Flags Checklist for Staff Here are the red flags to look out for. Red flags in the job posting The role is oddly vague or overly broad. Generic responsibilities, unclear reporting lines, and “we’ll share details later” language are common in fake listings. The company's presence doesn’t match the brand name. Thin company pages, inconsistent logos/branding, or a web presence that feels incomplete are worth pausing on. The process is “too easy, too fast.” If the listing implies immediate hiring with minimal steps, treat it as suspicious. Red flags in recruiter behaviour They push you off LinkedIn quickly. Moving to WhatsApp/Telegram or personal email early is a common tactic. They use a personal email address or unusual contact details. Be specifically cautious of recruiters using free webmail accounts instead of a company domain. They avoid verification. If they dodge basic questions, treat that as a signal, not a scheduling issue Hard-stop requests Any request for money or fees. Application fees, equipment purchases, “training costs”, gift cards, crypto, that’s a hard stop. Requests for sensitive personal info early. Bank details, identity documents, tax forms, or “background checks” before a real interview process is established. Requests for verification codes. If anyone asks you to read back a one-time code sent to your phone/email, assume they’re trying to take over an account. Requests for non-public company information like org charts, internal system details, client lists, invoice processes and security tools. Look out for requisitions for anything beyond what a recruiter would reasonably need. Stop Scams With Simple Defaults LinkedIn recruitment scams don’t succeed because staff are careless. They succeed because the outreach looks normal, the process feels familiar, and the next step is always framed as urgent. The fix isn’t turning everyone into an investigator. It’s setting simple defaults that make scams harder to complete: slow down before clicking, verify the recruiter and role through official channels, keep conversations on-platform until identity checks out, and treat money requests, code requests, and early personal data demands as hard stops.  When those habits are standardised, the scam loses its leverage.

The most dangerous thing in a server room is often the phrase, “Don’t touch that.” It’s usually said with a half-joke and a grimace. It refers to the old box that “still works”, runs something important, and has survived so many fixes and workarounds that nobody feels confident changing it anymore. That’s legacy debt. Not just “old tech”, but old tech that’s become a dependency. It’s the kind that quietly accumulates risk until it turns into downtime, security exposure, or an emergency upgrade at the worst possible time. A legacy debt audit is the fast way to bring that risk back into the light. What Legacy Debt Really Looks Like Legacy debt isn’t “old gear”. It’s old gear that has become normal. It’s the server that runs a critical app, the edge device nobody remembers buying, the workaround that turned into a dependency. Over time, that debt stacks up quietly. Infinite Lambda describes legacy debt as something that “happens even to the best systems,” “silently accruing costs and constraints,” and it can “accumulate basically unnoticed until it is too costly to ignore.” That’s why a legacy debt audit isn’t a theoretical exercise. It’s a visibility exercise to bring the oldest, highest-leverage risks back onto the list of things you actively manage. The security problem shows up when “old” becomes “unpatchable.” The UK’s NCSC guidance on obsolete products says, “Ideally, once out of date, technology should not be used,” and “the only fully effective way to mitigate this risk is to stop using the obsolete product.” If something can’t be updated, weaknesses don’t age out. They sit there, waiting for the wrong day. Legacy debt also looks like basic server hygiene slipping. NIST SP 800-123 frames secure server operations as an ongoing process: “Maintaining the secure configuration through application of appropriate patches and upgrades, security testing, monitoring of logs, and backups…” It also calls out foundational hardening steps like “Patch and upgrade the operating system” and “Remove or disable unnecessary services, applications, and network protocols.” When those basics become inconsistent, legacy debt turns into a reliability and incident-response problem, not just a security one. Finally, legacy debt often hides at the edge. If you have end-of-support internet-facing devices, you’ve got high-leverage risk in the most exposed place. The 3 Oldest Risks to Find First These three categories are where “old” most often turns into outsized risk, because they combine age with leverage: they either sit at the front door, can’t be fixed anymore, or have quietly drifted out of a safe baseline. Risk #1: End-of-support edge devices If you’re looking for high-leverage legacy debt, start at the edge. Firewalls, VPN gateways, routers, and other internet-facing devices are the front door to your environment. When they reach end-of-support (EOS), they don’t just become outdated. They become harder to defend because security fixes stop arriving. What to check in your audit List every edge device (firewall, VPN, router) and the support status for each one Confirm which ones are internet-facing and which services are exposed Identify devices that can’t run the current firmware or no longer receive updates. Risk #2: Obsolete products that can’t be fixed anymore Obsolete products are the purest form of legacy debt: things that are still operating but no longer receive security updates. That means every new vulnerability becomes permanent. In other words, there’s no clever workaround that makes an unsupported system “safe”. There are only risk reductions until you can replace it. What to check in your audit Identify anything past support: server OS versions, appliances, old hypervisors, and line-of-business apps Flag systems that require exceptions, like the ones with old protocols, weak auth, and special firewall rules Find the “business-critical but unsupported” systems. Risk #3: “It still works” servers with neglected basics This is the sneakiest risk because it looks normal. The server is supported. The hardware runs. Nobody’s complaining. But the basics have drifted: patching is inconsistent, unnecessary services are still running, and backups haven’t been proven under pressure. SP 800-123 Guide to General Server Security frames secure server operations as an ongoing discipline, including “patches and upgrades,” “monitoring of logs,” and “backups.” It also calls out core hardening steps like “Patch and upgrade the operating system” and “Remove or disable unnecessary services, applications, and network protocols.” Those are the unglamorous fundamentals that stop small problems from turning into long outages. What to check in your audit Patch reality: what’s the current patch level and how often do updates slip? Service sprawl: what’s running that doesn’t need to be running? Admin and service accounts: where are the broad permissions and shared credentials? Backup confidence: when was the last restore test and did it succeed? Change control: who can make changes, and how are they tracked? Stop Carrying Silent Risk Legacy debt doesn’t announce itself. It sits quietly in the background until the day it becomes downtime, exposure, or an emergency upgrade you didn’t plan for. A legacy debt audit gives you control back by turning “we should deal with that someday” into a shortlist you can act on. Start with the highest-leverage risks: end-of-support edge devices, obsolete products that can’t be patched, and servers where the basics have drifted. Then assign owners, set dates, and move one item at a time from “too scary to touch” to “handled”.  Contact us for help running your next legacy debt audit.

MFA is a strong front-door lock. But it’s not the only thing that decides whether someone can get in. After you sign in, your browser keeps you logged in using a session token (often stored as a cookie). It’s the digital version of a wristband at an event: once you’ve been checked, the wristband proves you belong there. If an attacker steals that wristband, they may not need to beat your MFA prompt at all. That’s the core of session cookie hijacking. The attacker isn’t “cracking” MFA. They’re skipping it by replaying your already authenticated session. This isn’t a reason to stop using MFA. It’s a reason to stop treating MFA as the finish line. When sessions can be stolen, the practical defence shifts to layered controls: phishing-resistant sign-ins, device hygiene, tighter session policies, and detection that catches suspicious access early. Why MFA Isn’t a “Game Over” Control MFA is still one of the best upgrades most businesses can make, but it doesn’t end an attack on its own. The reason is that attackers don’t always try to beat the login step. They try to go around it. Cloudflare notes that “attackers are finding new ways to circumvent MFA” and that modern incidents are rarely one isolated technique. They’re “part of a chain of attacks.” In other words, MFA can block a lot of credential theft, but it doesn’t automatically protect what happens after a user successfully signs in. That’s where session cookie hijacking comes in. Microsoft has described adversary-in-the-middle phishing campaigns where attackers use a reverse-proxy site to “steal and intercept” a user’s password and the session cookie that proves they have an authenticated session. This is “not a vulnerability in MFA.” The attacker isn’t breaking the MFA. They’re reusing the session. What a Session Cookie Is and Why Attackers Want It When you sign into a web app, the site needs a way to remember that you’ve already proved who you are. That’s what a session is: a temporary “logged-in” state that saves you from entering your password and MFA code on every click. Kaspersky explains that session hijacking is “sometimes called cookie hijacking” because cookies are commonly used to store the session identifier that keeps you authenticated. Attackers want that session identifier because it’s the shortcut. Proofpoint describes session tokens as digital “keys” that let a user stay authenticated. It warns that stealing valid tokens lets attackers impersonate legitimate users and potentially bypass authentication measures “like MFA.” That’s why session cookie hijacking is so highly leveraged. If an attacker can steal the cookie or token that represents your active session, they’re not trying to defeat the login process. They’re attempting to reuse what you already completed, and access the same apps and data as if they were sitting at your keyboard. How Session Cookie Hijacking Actually Happens A lot of teams picture “account takeover” as someone guessing a password or tricking a user into approving an MFA prompt. Session cookie hijacking is different. The attacker’s goal is to steal the proof that you’re already logged in, then reuse it, often without triggering another sign-in challenge. 1.) AiTM phishing Adversary-in-the-middle (AiTM) phishing is the “proxy login” trap. You think you’re signing into a normal service, but you’re actually signing into a lookalike page that sits between you and the real site. The attacker relays the login in real time, so everything appears to work, including MFA. Attackers use AiTM phishing sites to “steal and intercept” a user’s password and the session cookie that proves the authenticated session. This is “not a vulnerability in MFA.” The attacker isn’t breaking the MFA. They’re capturing the session after MFA is completed and reusing it. One such campaign “ attempted to target more than 10,000 organisations ” since September 2021, which shows how scalable this approach has become. 2.) Browser-in-the-Middle session stealing Browser-in-the-middle (BitM) is similar in spirit, but it’s even more “hands-on” from the attacker’s side. Instead of stealing a password and running away, the attacker effectively places themselves in control of the browsing session. Google’s threat intelligence says, “Stealing this session token is the equivalent of stealing the authenticated session.” Once the token is stolen, “an adversary would no longer need to perform the MFA challenge.” In other words, the attacker isn’t trying to authenticate instead of you. They’re trying to ride along after you’ve authenticated. 3.) Cookie theft from the endpoint Not every session hijack starts with a fancy proxy. Sometimes the attacker simply steals session data from the device itself. Stealing valid session tokens allows attackers to impersonate legitimate users. Tokens act like digital “keys.” If an endpoint is compromised, those “keys” can be extracted and reused. Invicti explains that an attacker steals HTTP cookies and can gain access. The goal is often to obtain sensitive information stored in cookies. MFA Is a Baseline, Not a Finish Line MFA is still essential. It blocks a huge amount of credential theft and makes basic account takeover harder. But session cookie hijacking is a reminder that attackers don’t always try to defeat the login step. Sometimes they reuse what happens after it. The practical response is layered and realistic. Make phishing harder to pull off, and treat device health as part of identity. Tighten session behaviour for high-risk apps. Watch for suspicious access patterns that suggest a session is being replayed. When those controls work together, MFA stops being a comforting checkbox and becomes what it should be: a strong baseline that’s backed by protections around the session itself.  Contact us today for help protecting your login sessions from hijacking.

In the traditional office, a “Clean Desk” policy was a simple habit: shred the sensitive stuff, lock it away, and don’t leave passwords where someone can see them. In 2026, the same idea still matters but the “desk” has changed. For many teams, the home office is now the default workspace, and that means physical access can quickly become digital access. An unlocked screen, a shared device, or a laptop left in the wrong place can expose the same systems your business runs on every day. Clean Desk 2.0 isn’t about aesthetics. It’s about securing the physical-to-digital bridge. If a houseguest, a delivery person, or a thief can sit down at your workstation, they don’t need to be a master hacker to cause real damage. They just need a few unattended minutes and an open session. Why an Unlocked Screen is a Data Breach Most small business owners treat multi-factor authentication (MFA) as the ultimate front-door lock. And it’s a great lock. The problem is that once you’re already inside, the “front door” isn’t the control that matters. When you sign into a web app, your browser creates a session token (often stored as a cookie) so you stay logged in without being challenged on every click. Kaspersky notes that session hijacking is “sometimes called cookie hijacking” because cookies commonly store the session identifier. Proofpoint says session tokens act like digital “keys.” If they’re stolen, attackers can impersonate legitimate users and bypass authentication measures “like MFA”. That’s why physical access changes the game. If someone can sit down at your workstation while you’re making a coffee, they don’t need to “crack” anything. They can reuse your already authenticated session and access the same cloud apps, CRM data, and financial tools you were just using, no MFA prompt required. This is exactly why Clean Desk 2.0 needs an auto-lock culture. Set short screen-lock timers. Lock manually every time you step away. Treat an unlocked session the same way you’d treat a set of master keys left in the door. Hardware "Legacy Debt" on Your Desk Most people keep old tech for the same reason: it still works. But “still works” isn’t the same as “still safe”. The same legacy debt that shows up in server rooms also shows up in home offices and often in the exact places that matter most, like routers, VPN gateways, and the “backup” laptop that hasn’t been updated in months. The core problem is end-of-support. When a device reaches end-of-support (EOS), security fixes stop arriving. The UK’s guidance on obsolete products notes, “Ideally, once out of date, technology should not be used,” and “the only fully effective way to mitigate this risk is to stop using the obsolete product.” In other words, you can’t patch your way out of something that no longer gets patches. This matters even more for edge devices. These are anything internet-facing that sits between your home network and the rest of the world. A Clean Desk 2.0 habit is to audit your home-office “edge” the same way you’d audit a server room: Identify what’s internet-facing Confirm it’s supported and patchable Retire anything that isn’t. Your Digital Employee Needs a Locked Door As AI features get embedded into everyday tools, workstations aren’t just “where you work” anymore. They’re where automated actions happen. An AI agent might update your CRM, draft client comms, schedule appointments, or move a workflow forward with minimal input once it’s been kicked off. That creates a new physical risk because unattended sessions + automation don’t mix. If an agent is running a process while you’re away from your desk, an unlocked screen turns into an open control panel. Someone doesn’t need to be technical to cause damage. They just need to click, approve, change a destination account, or interfere with an in-flight task. The fix isn’t banning automation. It’s treating AI-driven workflows like you’d treat any powerful business system: clear boundaries and clear approvals. Decide upfront: What decisions can the AI agent make without a human present? What actions require an explicit approval step? What are its spending limits and escalation rules if money is involved? Which systems and data are the agents allowed to access, and which are off-limits? Physical Efficiency and Cloud Waste A Clean Desk 2.0 mindset isn’t only about security. It’s about operational discipline: knowing what you’re using, why you’re using it, and what should be switched off when it’s not needed. Cloud waste is the digital version of leaving the lights on in an empty building. It shows up as underused servers, test environments that never power down, and storage that keeps growing because nobody owns the cleanup. None of it looks dramatic day to day. It just quietly inflates your monthly bill. The simple habit that fixes it is the same one that keeps a physical workspace under control: visibility and ownership. Assign each environment and major resource to an owner, review what’s actually being used, and schedule non-production workloads to shut down outside business hours. These “tidying” routines don’t just cut spending. They reduce clutter, limit exposure, and make your environment easier to manage when something goes wrong. Building a 2.0 Foundation Securing your home office from physical data leaks isn’t about paranoia. It’s about professionalism. In 2026, the home workspace isn’t a side setup. It’s part of your business perimeter. Clean Desk 2.0 is really a set of modern defaults, like locked screens and supported devices. When those basics are consistent, small home-office lapses stop turning into bigger business problems.  Want help turning this into a simple, enforceable baseline for your team? Contact us for a technology consultation.

When you first sign up for a software-as-a-service (SaaS) platform, everything is designed to feel effortless. The problem is that the first real test of a SaaS relationship isn’t the onboarding. It’s the exit. For many small businesses, the front door is wide open, but the emergency exit is bolted shut: exports are incomplete, key data sits in proprietary formats, and leaving requires expensive vendor help. That’s more than inconvenient. It’s a business risk. As teams move toward a workforce blended with humans and Agentic AI in 2026, your advantage will come from data you can move, reuse, and trust. If your data can’t leave a vendor cleanly, you don’t fully control your processes. Then your options, timelines, and costs are controlled for you. Why This Gets Worse in 2026 The “backup exit strategy” question is getting sharper in 2026 because SaaS sprawl and third-party dependence are now normal. Your business data isn’t sitting in one system. It’s spread across platforms, integrations, plug-ins, and automation. When one vendor changes pricing, terms, features, or risk profile, you don’t just “switch tools.” You either move your data cleanly or you stay stuck. The breach environment also raises the stakes. Verizon’s 2025 DBIR Executive Summary says it analysed 22,052 security incidents and 12,195 confirmed breaches, calling it “the highest number of breaches ever analysed in a single report,” across 139 countries. That volume matters because exits and migrations often happen under pressure. A backup exit strategy is what prevents “we need to move” from becoming “we can’t move.” Attackers are also increasingly focused on credentials and data pathways. These are the same pathways you rely on during exports and migrations. Microsoft’s Digital Defense Report 2025 notes that credential and access key theft attempts are up 23%, and attempts to extract sensitive data from storage accounts and databases increased 58%. Microsoft also reports that data collection showed up in 80% of reactive engagements, which is a reminder that “getting the data” is now a common objective. If you can’t export your data safely and predictably, you end up trapped. You can’t rotate away from a risky platform quickly. And you can’t migrate without creating new exposure. Finally, being stuck is expensive even before you factor in vendor fees. IBM’s Cost of a Data Breach Report 2025 puts the global average cost of a breach at USD 4.4M. That’s not a “lock-in” statistic, but it is a useful reality check: data incidents cost real money. A clean exit strategy reduces the chance that a vendor becomes an added cost multiplier during an already expensive situation. In 2026, the question isn’t whether you’ll ever need to move data. It’s whether you’ll be able to do it without vendor hand-holding, surprise costs, or emergency timelines. The Financial Cost of the "Proprietary Trap" A weak exit plan doesn’t just slow innovation. It quietly increases operating costs because you end up paying for a setup you can’t easily change. When you’re locked into a vendor, spending becomes sticky. You can’t right-size quickly, consolidate tools, or move workloads to a better-fit platform without turning it into a major project. That’s how waste hangs around. The real cost isn’t the monthly invoice. It’s the lack of options. When your data can’t move easily, every renewal, pricing change, or product shift becomes a forced decision instead of a strategic one. A true backup exit strategy flips that dynamic. It gives you the ability to migrate on your timeline, reduce duplicate tooling, and make cost decisions based on value rather than inertia. In practical terms, it turns “we can’t leave” into “we can compare, choose, and move when it makes sense.”. Securing the Move Once you decide to move your data, the migration itself becomes a high-risk moment. Not because migrations are inherently unsafe. But because they concentrate exactly what attackers want: High-privilege access Lots of open sessions, A lot of data moving at once During a data move, your team is often signed into multiple admin-level tools at the same time. That’s where session cookie hijacking becomes relevant. An attacker doesn’t need to “crack” your password if they can steal the session token that proves you’re already authenticated. Microsoft has described adversary-in-the-middle phishing campaigns that intercept session cookies so attackers can reuse an authenticated session and bypass the MFA prompt. Cloudflare also notes that attackers are finding ways to circumvent MFA as part of broader attack chains, which is why the safest approach is layered rather than relying on one control. To protect your backup exit migration: Use phishing-resistant sign-ins where possible for migration and admin accounts. Tighten session controls so privileged sessions expire sooner and re-authentication is required for risky actions. Treat device health as part of access: run the migration from a managed, patched, protected device. Monitor for suspicious access during the move. Ownership is a Discipline The businesses that thrive over the next few years won’t just adopt new tools. They’ll stay flexible as tools change. In a world of SaaS sprawl and AI-driven workflows, that flexibility comes from clean data, clear processes, and the ability to move when you need to.  If you’d like help building an exit-ready baseline across your vendor stack, contact us for a technology consultation.

Most small businesses aren’t breached because they have no security at all. They’re breached because a single stolen password becomes a master key to everything else. That’s the flaw in the old “castle-and-moat” model. Once someone gets past the perimeter, they can often move through the environment with far fewer restrictions than they should. And today, with cloud apps, remote work, shared links, and BYOD, the “perimeter” isn’t even a clearly defined boundary anymore. Zero-trust architecture for small businesses represents the shift that breaks that chain reaction. It’s an approach that treats every access request as potentially risky and requires verification every time. What Is Zero-Trust Architecture? Zero Trust is a model that moves defenses away from “static, network-based perimeters.” Instead, it focuses on “users, assets, and resources.” It also “ assumes there is no implicit trust granted to assets or user accounts ” based only on network location or ownership. Microsoft sets the idea down into a simple principle: the model teaches us to “never trust, always verify.” In practice, that means verifying each request as though it came from an uncontrolled network, even if it’s coming from the office. IBM reports that the global average cost of a data breach is over $4 million, which is why reducing blast radius isn’t a nice-to-have. So, what does “Zero Trust” actually do differently day to day? Microsoft frames it around three core principles: verify explicitly, use least privilege access, and assume breach. In small-business terms, that usually translates to: Identity-first controls: Strong MFA, blocking risky legacy authentication, and applying stricter policies to admin accounts. Device-aware access: Evaluating who is signing in and whether their device is managed, patched, and meets your security standards. Segmentation to limit impact: Breaking your environment into smaller zones so access to one area doesn’t automatically grant access to everything else. Cloudflare describes microsegmentation as dividing perimeters into “small zones” to prevent lateral movement between systems. Before You Start If you try to “implement Zero Trust” everywhere at once, two things usually happen: 1. Everyone gets frustrated. 2. Nothing meaningful gets completed. Instead, start with a defined protect surface, a small group of critical systems, data, and workflows that matter most and can realistically be secured first. What Counts as a “Protect Surface”? A protect surface typically includes one of the following: A business-critical application A high-value dataset A core operational service A high-risk workflow The 5 Surfaces Most Small Businesses Start With If you’re unsure where to begin, this shortlist applies to most environments: 1. Identity and email 2. Finance and payment systems 3. Client data storage 4. Remote access pathways 5. Admin accounts and management tools BizTech makes the point that there’s no “Zero Trust in a box.” It’s achieved through the right mix of people, process, and technology. The Roadmap This is where zero-trust architecture for small businesses stops being a concept and becomes a plan. Each phase builds on the one before it, so you get meaningful risk reduction without creating a security obstacle course. 1. Start with Identity Network location should not be treated as a trusted signal . Access should be based on who or what is requesting it, and whether they should have access at that moment. That’s why identity is step one. Do this first: Enforce multifactor authentication (MFA) everywhere Remove weak sign-in paths Separate admin accounts from day-to-day user accounts 2. Bring Devices into the Trust Decision Zero Trust isn’t just asking, “Is the password correct?” It’s asking, “Is this device safe to trust right now?” Microsoft’s SMB guidance explicitly calls out securing both managed devices and BYOD, because small businesses often have a mix. Keep it simple: Set a clear baseline: patched operating systems, disk encryption, and endpoint protection Require compliant devices for access to sensitive applications and data Establish a clear BYOD policy: limited access, not unrestricted access 3. Fix Access Microsoft’s principle here is “use least privilege access.” This means users should have only what they need, when they need it, and nothing more. Practical moves: Eliminate broad “everyone has access” groups and shared login accounts Shift to role-based access, where job roles determine defined access bundles Require additional verification for admin elevation, and make sure it’s logged 4. Lock Down Apps and Data The old perimeter model doesn’t map cleanly to cloud services and remote access, which is why organizations shift towards a model that verifies access at the resource level. Focus on your protect surface first: Tighten sharing defaults Require stronger sign-in checks for high-risk apps Clarify ownership: every critical system and dataset needs an accountable owner 5. Assume Breach Microsegmentation divides your environment into smaller, controlled zones so that a breach in one area doesn’t automatically expose everything else. That’s the whole point of “assume breach”: contain, don’t panic. What to do: Segment critical systems away from general user access Limit admin pathways to management tools Reduce lateral movement routes 6. Add Visibility and Response Zero Trust decisions can be informed by inputs like logs and threat intelligence . Because verification isn’t a one-time event, it’s ongoing Minimum viable visibility: Centralize sign-in, endpoint, and critical app alerts Define what counts as suspicious for your protect surface Create a simple response Your Zero-Trust Roadmap Zero Trust architecture for small businesses doesn’t begin with a shopping list. It begins with a clear, focused plan. If you’re ready to move from “good idea” to real implementation, start with a single protect surface and commit to the next 30 days of measurable improvements. Small steps, consistent execution, and fewer unpleasant surprises.  If you’d like help defining your protect surface and building a practical Zero Trust roadmap, contact us today for a consultation. We’ll help you prioritize the right controls, align them to your environment, and turn Zero Trust into steady progress, not complexity.

If you want to uncover unsanctioned cloud apps, don’t begin with a policy. Start with your browser history. The cloud environment most businesses actually use rarely matches the one shown on the IT diagram. It’s built through countless small shortcuts: a “just this once” file share, a free tool that solves one problem faster, a plug-in installed to meet a deadline, or an AI feature quietly enabled inside an app you already pay for. In the moment, none of it feels like a problem. It feels efficient. Helpful. Until it isn’t. Then you realise business data is scattered across tools you didn’t formally approve, accounts you can’t easily offboard, and sharing settings that don’t reflect the actual risk. Why Unsanctioned Cloud Apps Are a 2026 Problem Unsanctioned cloud apps have always existed. What’s changed this year is the scale, the speed, and the fact that “cloud apps” now include AI features hiding in plain sight. Start with scale. Microsoft’s shadow IT guidance points out that most IT teams assume employees use “30 or 40” cloud apps, but “in reality, the average is over 1,000 separate apps.” It also notes that “80% of employees use non-sanctioned apps” that haven’t been reviewed against company policy. That’s the uncomfortable reality of unsanctioned cloud apps: the gap between what you believe is happening and what’s actually happening is often far wider than expected. Now add the 2026 twist: AI isn’t just a standalone tool employees consciously choose to use. The Cloud Security Alliance notes that AI is increasingly embedded as a feature within everyday business applications, rather than existing only as a standalone tool. In other words, you can have shadow AI risk without anyone signing up for a new AI product. It’s just… there. That creates a different kind of exposure. The same Cloud Security Alliance article cites research showing “54% of employees” admit they would use AI tools even without company authorisation. It also references an IBM finding that “20% of organisations” experienced breaches linked to unauthorised AI use, adding an average of “$670,000” to breach costs. So, this isn’t just a governance problem. It’s a measurable risk problem. And here’s the final reason 2026 feels different: the old “block it and move on” strategy no longer works. The Cloud Security Alliance has pointed out that simply blocking cloud apps isn’t an option anymore because cloud services are woven into everyday work. If you don’t provide a secure alternative, employees will find another workaround. Don’t Start with Blocking The fastest way to drive cloud app usage further underground is to treat it as a discipline problem and respond with bans. Yes, some applications do need to be blocked. But if blocking is your first move, it typically creates two unintended side effects: 1. People get better at hiding what they’re doing. 2. They switch to a different tool that’s just as risky or, sometimes, worse. Either way, you haven’t reduced the problem. You’ve just made it harder to see. A better starting point is to understand what’s happening and why. The recommendation is to evaluate cloud app risk against an “ objective yardstick ”. You should monitor what users are actually doing in those apps so you can focus on the behaviour that creates exposure, not just the name of the tool. Once you have that visibility, you can respond in a way that actually lasts. Some apps will be approved. Others may be restricted. Some will need to be replaced. And the truly high-risk ones? Those are the apps you block thoughtfully, with a clear plan, a communication message, and a secure alternative that allows people to keep doing their jobs. The Practical Workflow to Uncover Unsanctioned Cloud Apps This isn’t a one-time clean-up. It’s a workflow you can run quarterly (or continuously) to stay ahead of new tools and new habits. Discover What’s Actually in Use Start by generating a real inventory from the signals you already collect: endpoint telemetry, identity logs, network and DNS data, and browser activity. Microsoft’s shadow IT tutorial emphasises a dedicated discovery phase, because you can’t manage what you haven’t first identified. Analyse Usage Patterns Don’t stop at identifying which apps are in use. Review things like: Who is accessing cloud apps What admin activity is happening Whether data is being shared publicly or with personal accounts Access that should no longer exist, such as former employees who still have active connections Score and Prioritise Risk Not every unsanctioned app is equally dangerous. Use a simple risk lens: The sensitivity of the data involved How information is being shared The strength of identity controls The level of administrative visibility Whether AI features could be ingesting or exposing data Tag Apps Make decisions visible and repeatable by tagging apps. Microsoft explicitly calls tagging apps as sanctioned or unsanctioned an important step, because it lets you filter, track progress, and drive consistent action over time. Take Action Once an app is tagged, you can enforce the decision. Microsoft’s governance guidance outlines two practical responses: issuing user warnings, a lighter control that encourages better behaviour, or blocking access to applications that present unacceptable risk. Just keep in mind that changes aren’t always immediate. Plan for communication and a smooth transition, rather than triggering unexpected disruptions. Your New Default: Discover, Decide, Enforce Unsanctioned cloud apps aren’t disappearing in 2026. If anything, they’ll continue to multiply, especially as new AI features appear inside the tools your team already relies on. The goal isn’t to block everything. It’s to create a repeatable operating model: discover what’s in use, determine what’s acceptable, and enforce those decisions with clear guidance and secure alternatives. When you apply that consistently, cloud app sprawl stops being a surprise. It becomes another controlled, managed part of your environment.  If you’d like help building a practical cloud app governance process that fits your organisation, contact us today. We’ll help you gain visibility, reduce exposure, and put guardrails in place, without slowing productivity.