Tag: Security

Building Conditional Access That Actually Works: Requiring Intune‑Compliant Devices

image

Requiring Intune‑compliant devices via Conditional Access is one of the most impactful controls available to Microsoft 365 Business Premium tenants. It’s also one of the easiest ways to accidentally break access if you don’t understand how the moving parts fit together.

This article walks through the end‑to‑end mechanics, not just the clicks, so L2/L3 engineers understand why policies behave the way they do.

Architecture: What Happens During Sign‑In

When a user signs into a cloud app (Exchange Online, SharePoint, Teams):

  1. Microsoft Entra ID evaluates applicable Conditional Access policies

  2. If a policy requires a compliant device, Entra queries Intune
  3. Intune returns a binary verdict: Compliant or Not compliant
  4. Access is granted or blocked accordingly

Microsoft explicitly states that Conditional Access relies on Intune compliance state and will not function as intended without an Intune compliance policy in place. [learn.microsoft.com]

This is not a soft dependency — no compliance policy means every device fails the check.

Step 1: Define “Compliant” in Intune (Before Touching Conditional Access)

In the Intune admin centre (intune.microsoft.com):

Devices → Compliance policies → Create

At minimum for Windows endpoints in Business Premium, Microsoft supports compliance checks such as:

  • BitLocker enabled

  • Secure Boot enabled

  • Minimum OS version

  • Antivirus and firewall present

These controls form the inputs to Conditional Access — they do nothing by themselves. [learn.microsoft.com]

Operational tip:
Assign compliance policies to user groups, not devices. Conditional Access evaluates user sign‑ins, not device objects.

Step 2: Create the Conditional Access Policy

In the Microsoft Entra admin centre (entra.microsoft.com):

Protection → Conditional Access → Policies → New policy

Core configuration (baseline):
  • Users
    • Include: Target user group (do not start with All users)

    • Exclude:

      • Emergency access (break‑glass) accounts

      • Service accounts (where applicable)

Microsoft explicitly recommends excluding emergency access accounts to avoid tenant lockout. [learn.microsoft.com]

  • Target resources

    • Start with: Exchange Online or Office 365

    • Expand later to “All cloud apps”

  • Grant

    • ✅ Require device to be marked as compliant

  • Enable

    • ✅ Report‑only (initially)

This exact flow is documented by Microsoft as the supported deployment approach. [learn.microsoft.com]

Step 3: Report‑Only Mode Is Not Optional

Report‑only mode evaluates the policy without enforcing it. This allows you to:

  • Confirm which users would be blocked

  • Identify unmanaged or unenrolled devices

  • Detect users authenticating from unsupported platforms

Microsoft strongly recommends Report‑only mode before enforcement for Conditional Access policies of this type. [learn.microsoft.com]

Validation path:

  • Entra ID → Sign‑in logs

  • Filter: Conditional Access → Report‑only

  • Review failure reasons

Step 4: Common Failure Scenarios (Seen in the Wild)

“User prompted repeatedly for MFA then blocked”
  • Device is Entra ID joined but not enrolled in Intune
  • No compliance policy applies to the user
“macOS or BYOD phones blocked unexpectedly”
  • Platform not covered by a compliance policy

  • Device enrolment incomplete
“Policy works for admins but not staff”
  • Admins often use already‑managed devices

  • Staff devices lag behind in enrolment

Microsoft documents that Conditional Access can only evaluate compliance for MDM‑enrolled devices. [learn.microsoft.com]

Step 5: When Not to Use Compliant‑Only Access

Microsoft explicitly provides alternative templates where compliance is one of several controls, not the only one, such as:

  • Compliant device OR Microsoft Entra hybrid joined OR MFA

This is recommended where full device management is not realistic. [learn.microsoft.com]

Production Roll‑Out Recommendation

For Business Premium tenants, Microsoft’s own Zero Trust guidance aligns to:

  1. Require MFA first

  2. Enrol devices into Intune

  3. Require compliant devices for core workloads

  4. Expand to all cloud apps once stable [learn.microsoft.com]

Official Microsoft References

What’s actually happening inside an Intune App Protection Policy

image

Most MSPs I work with have shipped App Protection Policies (APP) to a client by now. BYOD iPhone, Outlook Mobile, a PIN, a block on copy-paste to personal apps — done, move on. But when the client’s compliance consultant asks how the data is actually protected, or why a specific action blocks on an unenrolled Android, the hand-waving starts. Here’s what’s actually going on under the covers.

The Intune App SDK, not the OS, is doing the work

An App Protection Policy doesn’t manage the device. That’s the whole point of MAM-without-enrolment. Enforcement lives inside the app itself, courtesy of the Intune App SDK that Microsoft has compiled into Outlook, Teams, Word, Excel, OneDrive, and a growing list of line-of-business apps wrapped with the App Wrapping Tool. When the user signs in with their work identity, the SDK phones home to the Intune service, pulls down the policy that applies to that user plus that app, and starts enforcing it in-process.

That’s why policies are scoped to user and app, not device. The OS on an unenrolled phone has no idea this is happening. The app is quietly running a second policy engine beside the operating system — and a separate wipe scope, which is what lets you revoke org data from a personal device without nuking the phone.

The broker is the hinge

On iOS, Microsoft Authenticator acts as the broker. On Android, it’s Company Portal — even when no device enrolment exists. The broker holds the work identity token and passes it to every SDK-enabled app, which is why one PIN prompt in Outlook covers Teams and Word for the next session. If the broker isn’t installed, APP quietly degrades: the SDK still enforces policy on its own app, but cross-app single sign-on and some advanced integrity checks fall away. A detail worth surfacing in onboarding.

Conditional launch is a local state machine

The under-appreciated piece is Conditional Launch. Every time a managed app resumes, the SDK runs a checklist: is the OS version above the floor, is the device jailbroken or rooted, is the Play Integrity or App Attest result clean, is the user still in good standing with Entra ID, how long since the last check-in? If any requirement fails, the SDK can warn, block, or selectively wipe org data — on its own, from a cached policy, without Intune needing to reach the device at that moment.

The data boundary works the same way. “Save copies of org data” restricted to OneDrive for Business, “Open-in” restricted to other managed apps, encrypted cache at rest — these are decisions made inside the app process by asking the SDK whether the target app is on the allow list and signed in with the same work identity.

Where Conditional Access joins in

The final layer is the Entra ID grant control Require app protection policy. This is what makes APP enforceable rather than optional. The token issued to the app is stamped with a claim confirming the app is compliant with its APP at sign-in. Conditional Access can refuse the token entirely if the app isn’t protected, and with Continuous Access Evaluation the refusal can happen mid-session. That’s the seam between the identity plane and the data plane.

What I’d tell a junior engineer

APP is a policy engine bolted into each app, gated by the broker, validated by Conditional Access. Understand those three layers and the “why did this break” tickets get a lot shorter.

Worth bookmarking:

Windows LAPS via Intune: the quiet Business Premium win most MSPs still haven’t shipped

image

Walk into almost any SMB estate and you’ll find the same thing — a local administrator password that was set during imaging three years ago, shared across every device, and written down somewhere nobody wants to admit. It’s the sort of gap that never shows up on a client’s risk register until it does. What surprises me is how many MSPs haven’t yet rolled out Windows LAPS, even though it’s sitting right there inside Microsoft 365 Business Premium — Intune is part of the licence, the feature is part of Windows, and there’s no extra agent to push.

What it actually is

Windows LAPS is the successor to the old “Microsoft LAPS” tool — the one that needed an AD schema extension and a client-side extension pushed by GPO. The replacement is baked into Windows 10, Windows 11, and Server 2019+. Nothing to install. You just tell it what to do.

Each managed device backs its local admin password up to a directory — either on-prem AD or Entra ID. Pick one per device, and for cloud-joined SMB fleets it’s almost always Entra. The password is stored encrypted against an Entra key, and only users holding the right role can read it. The device itself never keeps the current password in the clear once it has rotated.

Deploying through Intune

In the Intune admin centre it lives under Endpoint security → Account protection → create a policy of type Local admin password solution (Windows LAPS). Under the hood you’re configuring the LAPS CSP, but the UI hides that detail.

The settings worth thinking through:

  • Backup directory — Azure AD or Active Directory. Disabled turns it off.

  • Administrator account name — leave blank and it manages the built-in Administrator, which is disabled by default on most modern builds. Name it explicitly if you want LAPS to manage a dedicated local admin.

  • Automatic account management — the newer setting that lets LAPS create and maintain the account for you, so you don’t need a separate provisioning step.

  • Password complexity, length, age — 14+ characters, full complexity, 30-day rotation is a sensible baseline.

Assign the policy to an Entra device group, not a user group — it’s a device-scoped CSP and won’t apply against user targeting.

Rotation, post-authentication reset, and retrieval

The bit that’s genuinely new — and the bit most pros miss — is the post-authentication reset. When the managed account signs in interactively, Windows starts a grace timer. When that elapses, it can rotate the password, sign the account off, or reboot the device. That behaviour alone shuts the door on a technician staying signed in for days with a password someone else might already have read. Scheduled rotation still runs on the age you set, and you can force an on-demand rotation from the device blade in Intune.

Retrieval is the other place it pays for itself. In Intune, open the device and click Local admin password. Or do it from Entra directly — Devices → the device → Local administrator password recovery. The role needed is Cloud Device Administrator, or an Intune role with the right retrieval action. Every read is audited, and by default reading the password triggers a fresh rotation, so a looked-up credential is a one-shot — useful if you’re handing it to a junior tech for a single call.

Worth the morning it takes

Rolling this out across a client tenant is an afternoon’s work per fleet, and it closes a gap most MSPs have been quietly carrying for years. If you’re already selling Business Premium, you’re already paying for it. The only real question left is why it isn’t deployed yet.

Step-by-step: Find deleted file logs for a SharePoint site

image

Option 1: Use the Microsoft Purview audit portal

This is the easiest method for most admins.

  1. Sign in to Microsoft 365

  2. Open Audit

    • In the left menu, go to Solutions > Audit.

    • If prompted, enable auditing if it isn’t already on.

  3. Start a new search

    • Select New Search.

  4. Set the date range

    • Choose the period when you think the file was deleted.

    • Be aware that audit retention depends on licensing:

      • Many non-E5 tenants keep audit data for 180 days
      • E5 and some add-on licenses can retain some audit data for 1 year by default citehttps://learn.microsoft.com/purview/audit-search#before-you-search-the-audit-log

  5. Choose activities

    • In the activity filter, look for SharePoint file deletion-related actions such as:

      • Deleted file (FileDeleted)

      • Recycled a file (FileRecycled)

      • Deleted file from recycle bin (FileDeletedFirstStageRecycleBin)

      • Deleted file from second-stage recycle bin (FileDeletedSecondStageRecycleBin) citehttps://learn.microsoft.com/purview/audit-log-activities#file-and-page-activities

  6. Filter by site, file, or user

    • Use available filters to narrow results:

      • Site URL
      • File name
      • User
    • If you know the person who deleted the file, filtering by user makes results much easier to review.

  7. Run the search

    • Click Search.

  8. Review the results

    • Open matching events to see details such as:

      • who performed the action

      • when it happened

      • the file involved

      • the site URL

      • the operation type

  9. Check the event sequence

    • A typical deletion trail may look like this:

      • FileRecycled = file moved to recycle bin

      • FileDeletedFirstStageRecycleBin = removed from first-stage recycle bin

      • FileDeletedSecondStageRecycleBin = permanently removed from second-stage recycle bin citehttps://learn.microsoft.com/purview/audit-log-activities#file-and-page-activities

What the log entries mean

For SharePoint deleted files, these are the most useful audit events:

  • FileDeleted
    A user deleted a document from a site. citehttps://learn.microsoft.com/purview/audit-log-activities#file-and-page-activities

  • FileRecycled
    A user moved a file into the SharePoint recycle bin. citehttps://learn.microsoft.com/purview/audit-log-activities#file-and-page-activities

  • FileDeletedFirstStageRecycleBin
    A user deleted a file from the site’s recycle bin. citehttps://learn.microsoft.com/purview/audit-log-activities#file-and-page-activities

  • FileDeletedSecondStageRecycleBin
    A user deleted a file from the second-stage recycle bin. citehttps://learn.microsoft.com/purview/audit-log-activities#file-and-page-activities

That sequence helps you determine whether the file is still recoverable or has been permanently removed.

Practical tip for small businesses

If you are only trying to answer:

  • Who deleted the file?
  • When was it deleted?
  • Was it permanently deleted or just moved to the recycle bin?

Then the audit search with the filters:

  • date range

  • user

  • file name

  • SharePoint activities

is usually enough.

If you are trying to restore the file as well, you should also check:

  • the site recycle bin
  • the second-stage recycle bin

because the audit log tells you what happened, but recovery depends on whether the file is still retained in one of those recycle bins.

Option 2: Use PowerShell for more detailed searches

If you prefer scripting or want to export results, Microsoft also supports using the Search-UnifiedAuditLog cmdlet in Exchange Online PowerShell to search and export audit records. citehttps://learn.microsoft.com/purview/audit-log-export-records#use-powershell-to-search-and-export-audit-log-records

High-level process:

  1. Connect to Exchange Online PowerShell.

  2. Run Search-UnifiedAuditLog for the date range.

  3. Search SharePoint-related audit records.

  4. Export the results to CSV for filtering and reporting. citehttps://learn.microsoft.com/purview/audit-log-export-records#use-powershell-to-search-and-export-audit-log-records

This is especially useful if:

  • you need a report,

  • you want to search a large range of data,

  • or you want to automate the process.

Things to check if you can’t find the log

If no results appear, check these common causes:

  1. Wrong date range

    • Expand the time window.

  2. Audit retention expired

    • Older events may no longer be available depending on license. citehttps://learn.microsoft.com/purview/audit-search#before-you-search-the-audit-log

  3. Wrong activity selected

    • Try both:

      • deleted

      • recycled

      • recycle bin deletion events

  4. Auditing not enabled

    • In most tenants this is on, but if it was disabled previously, older activity may not exist. Microsoft notes audit log ingestion can be turned on or off. citehttps://learn.microsoft.com/purview/audit-search#before-you-search-the-audit-log

  5. Looking in SharePoint site settings instead of Purview

    • File deletion history is generally tracked in the Microsoft 365 unified audit log, not as a simple “deletion report” inside the SharePoint site itself.

Simple example

If a user says, “The file Budget.xlsx disappeared from the Finance SharePoint site,” you would:

  1. Open Purview Audit
  2. Search the last 7–30 days

  3. Filter activities to:

    • FileDeleted

    • FileRecycled

    • FileDeletedFirstStageRecycleBin

    • FileDeletedSecondStageRecycleBin
  4. Filter by:

    • Site URL = Finance site

    • File name = Budget.xlsx
  5. Review who deleted it and whether it is still recoverable

Existing systems can now enable Windows Smart App Control (and you should)

Screenshot 2026-04-16 210136

What Windows Smart App Control actually is

Smart App Control (SAC) is a pre‑execution application control layer built into Windows 11 that blocks untrusted software before it runs. It lives in Windows Security → App & browser control, and operates independently from Microsoft Defender Antivirus and SmartScreen. [support.mi…rosoft.com], [computerworld.com]

This is important:

Smart App Control is not antivirus.
It is policy‑enforced app allow/deny at launch time, based on trust and reputation.

Think of it as Microsoft sneaking a consumer‑friendly WDAC‑lite into Windows 11.

The security model: how SAC makes decisions

When any executable (EXE, DLL, MSI, script, etc.) attempts to run, Smart App Control applies a deterministic trust pipeline:

1. Cloud reputation check first

Windows queries Microsoft’s cloud‑based app intelligence service, which analyses signals from billions of executions worldwide. [support.mi…rosoft.com], [computerworld.com]

If the app is:

  • Known good

  • Widely deployed

  • Previously classified as safe

➡ It runs

2. Certificate trust validation

If cloud intelligence cannot confidently classify the app, SAC checks:

  • Is the file digitally signed?

  • Is the certificate trusted and valid?

  • Has the binary been tampered with?

Signed software from reputable vendors typically passes this stage. [support.mi…rosoft.com], [howtogeek.com]

➡ Valid signature = allowed

3. Everything else is blocked

If the app is:

  • Unsigned

  • Unknown

  • Newly compiled custom binaries

  • Internally built tooling

➡ Smart App Control blocks execution

There is no “Run anyway”, no whitelist, and no user override in enforcement mode. That is entirely by design. [computerworld.com], [howtogeek.com]

The three Smart App Control states (this matters)

SAC operates in three mutually exclusive modes:

1. Evaluation mode
  • SAC runs silently

  • Nothing is blocked

  • Windows observes your real‑world app usage

  • SAC decides if your system is “compatible” with strict enforcement

This was originally only triggered on clean installs. [howtogeek.com]

2. Enforcement (On)
  • Unknown or untrusted apps are blocked at launch

  • No user bypass

  • No per‑app exceptions

  • Logs are written to Windows Security / Event Viewer

This is where SAC actually provides protection.

3. Off
  • No checks

  • No enforcement

  • Until recently, this was permanent without OS reinstall

Why Smart App Control was widely ignored (until now)

From a pure security model perspective, SAC was solid.
From a real‑world usability perspective, it was borderline hostile.

Until early 2026:

  • If you disabled SAC once, it could never be turned back on
  • Re‑enablement required a full Windows reinstall or reset
  • Upgraded systems were locked to Off
  • MSPs, developers, and power users effectively couldn’t touch it

Microsoft openly acknowledged this rigidity in its own documentation. [support.mi…rosoft.com]

So the result?

Everyone who actually understands Windows workflows turned it off permanently.

What changed in 2026 (this is the big deal)

April 2026 Windows 11 security updates fundamentally changed SAC’s lifecycle

Microsoft removed the “one‑way switch” limitation.

As of the April 2026 Windows 11 updates (24H2 / 25H2):

✅ Smart App Control can now be turned ON after install
✅ Smart App Control can be re‑enabled after being turned off
✅ No OS reinstall required
✅ Managed via Windows Security UI

This change is explicitly documented by Microsoft and multiple independent sources. [techrepublic.com], [pureinfotech.com], [windowsreport.com], [msn.com]

Where the toggle now lives
Windows Security
→ App & browser control
→ Smart App Control
→ Smart App Control settings

From there, you can:

  • Switch On
  • Switch Off
  • Let systems enter Evaluation again

[techrepublic.com], [pureinfotech.com]

What did not change (important limitations remain)

Microsoft did not soften SAC’s enforcement model:

  • ❌ Still no per‑app allow

  • ❌ Still blocks unsigned internal apps

  • ❌ Still unsuitable for dev workstations

  • ❌ Still excluded from enterprise‑managed devices

The decision engine is unchanged. Only the lifecycle control was fixed. [msn.com]

Who Smart App Control now makes sense for

✅ Excellent fit
  • SMB users
  • Standard staff PCs
  • BYOD devices
  • Non‑technical users
  • High‑risk email / web exposure roles

Especially when paired with:

  • Defender Antivirus

  • Attack Surface Reduction rules

  • Defender SmartScreen

❌ Poor fit
  • Developers

  • MSP admin machines

  • Script‑heavy workflows

  • Legacy Line‑of‑Business apps

  • Custom PowerShell tooling

For these, WDAC, AppLocker, or Intune‑managed policy is still the correct solution.

MSP‑level takeaway (opinionated, but grounded)

Smart App Control finally crossed the line from:

“Technically interesting but unusable”

to:

“Deployable baseline protection for unmanaged Windows 11 PCs”

It is not a replacement for:

  • Application control

  • Device management

  • Security policy

But it is now a credible default deny layer for Windows 11 endpoints that previously had none.

Capability beats resources every single time

image

Most organisations don’t fail because they lack tools, money or technology. They fail because they lack the capability to use what they already have to produce good outcomes.

That might sound blunt, but it’s one of the most consistent patterns I see across businesses, MSPs and IT teams.

They have Microsoft 365.
They have security products.
They have AI tools.
They have documentation, frameworks, policies and “best practice”.

And yet outcomes are poor.

Why? Because capability matters more than availability.

Having access is not the same as being capable

Modern business environments are stacked with resources. Cloud platforms, SaaS tools, automation, AI copilots, security dashboards — the list keeps growing.

But access to resources doesn’t magically translate into results.

Capability is what turns potential into performance.

Capability means:

  • Knowing what to use
  • Knowing when to use it
  • Knowing why it matters
  • And being able to apply it consistently under pressure

Without that, more tools just add more noise.

I’ve seen organisations buy premium licences, deploy advanced features, and still operate like nothing changed — because nobody actually knew how to use the capability to drive outcomes.

Outcomes don’t come from features — they come from execution

This is where many technology discussions go off the rails.

The focus shifts to:

  • “What features do we have?”

  • “What licence do we need?”

  • “What tool should we buy next?”

Instead, the better question is: What outcome are we trying to achieve, and do we have the capability to get there?

Security is a perfect example.

Buying security tools doesn’t make you secure.
Configuring policies once doesn’t make you resilient.
Compliance frameworks don’t implement themselves.

Outcomes like reduced risk, faster recovery, safer users and better decision‑making only happen when people understand how to use the tools as part of a system, not as isolated checkboxes.

Capability is a multiplier

Resources on their own are static. Capability is a force multiplier.

Two organisations can have the same tools and budgets, yet one dramatically outperforms the other. The difference is rarely technology. It’s capability.

High‑capability teams:

  • Adapt faster when things change

  • Get more value from fewer tools

  • Recover quicker when things go wrong

  • Make better decisions with incomplete information

Low‑capability teams:

  • Depend on vendors to think for them

  • Struggle when documentation is outdated

  • Freeze when incidents don’t follow the playbook

  • Keep buying “solutions” to fix people problems

Capability compounds over time. Tools depreciate. Skills appreciate.

Capability is built, not installed

This is the uncomfortable truth many leaders avoid.

You can’t deploy capability with a script, a purchase order or a project plan.

Capability is built through:

  • Repetition

  • Context

  • Practice

  • Feedback

  • Failure (and learning from it)

That’s why checklists alone don’t work.
That’s why “we sent them on a course” doesn’t stick.
That’s why shelfware exists.

People become capable when they use resources to solve real problems, not when they memorise features.

MSPs: this is your real value

For MSPs, this is where the opportunity — and responsibility — lies.

Clients don’t need more tools. They need better outcomes.

Your value isn’t:

  • Installing another product

  • Enabling another feature

  • Sending another report nobody reads

Your value is helping clients build the capability to use what they already have to:

  • Reduce risk

  • Improve productivity

  • Make better decisions

  • Sleep better at night

That means shifting conversations away from tools and towards outcomes, behaviour and repeatable execution.

Ask better questions

If you want better outcomes, start asking better questions:

  • What are we actually trying to improve?

  • What decisions should this capability enable?

  • Who needs to act differently as a result?

  • What happens if this fails at 2am on a Sunday?

  • Can this be repeated, not just demonstrated once?

These questions expose gaps in capability far faster than another product demo ever will.

The bottom line

Resources are everywhere. Capability is rare.

The organisations that win aren’t the ones with the biggest stacks — they’re the ones that can use what they have well, consistently, and under pressure.

If you care about outcomes, stop asking what else you need to buy.

Start asking whether you’re capable of using what you already have.

Because capability — not access — is what produces good outcomes.

Stop Selling Tools. Start Delivering Security Outcomes.

image

One of the biggest mistakes I see in SMB security is confusing owning security tools with being secure.

“We’ve got MFA.” “We’ve got Defender.” “We’ve got backups.” “We’ve got a firewall.”

Great. None of those are outcomes.

They’re ingredients.

Security outcomes are what actually matter to the business — and if you don’t frame your security work that way, you end up with clients who think they’re safe right up until the day they’re not.

Tools Don’t Stop Incidents. Outcomes Do.

An SMB doesn’t wake up worried about Conditional Access policies or EDR configurations.

They worry about:

  • Getting locked out of email

  • Paying a ransom

  • Losing customer data

  • Missing payroll

  • Failing a cyber insurance claim

  • Being offline for days

Those are business outcomes — and security should be measured against how well it prevents or limits those events, not how many licences are assigned.

Owning a tool doesn’t mean it’s configured correctly. Having it configured doesn’t mean it’s monitored. Monitoring doesn’t mean anyone knows what to do when something breaks.

Security only exists when all of those pieces work together to achieve a real‑world result.

Outcome‑Driven Security Changes the Conversation

When you focus on outcomes, the conversation with SMBs changes dramatically.

Instead of saying:

“We’re deploying Microsoft Defender.”

You say:

“We’re reducing the chance that ransomware takes out your business — and if it does get in, we’ll detect it early and recover fast.”

Instead of:

“We’re enforcing MFA.”

You say:

“We’re stopping attackers from logging in as your staff, even if passwords are stolen.”

Instead of:

“We’ve configured backups.”

You say:

“If everything is encrypted tomorrow, we can restore your critical systems within hours, not days.”

Same tools. Completely different value.

The Outcome Stack Most SMBs Actually Need

If you strip away the marketing noise, most SMB security outcomes fall into a few simple buckets:

1. Prevent the most common attacks Phishing, credential theft, malware, token abuse. Outcome: attackers struggle to get in.

2. Limit blast radius If someone does get in, they can’t access everything. Outcome: one compromised account doesn’t become a company‑wide incident.

3. Detect quickly Alerts fire early, not days later. Outcome: incidents are contained before they become disasters.

4. Recover confidently Backups work, restores are tested, roles are clear. Outcome: downtime is measured in hours, not weeks.

5. Prove it Evidence exists for insurance, audits, and management. Outcome: no scrambling, no guesswork, no “we think it’s set”.

Notice something?

None of those outcomes mention a specific product.

Why Tool‑First Security Fails SMBs

SMBs are especially vulnerable to tool‑centric security because:

  • Licences get sold but not fully configured

  • Defaults are mistaken for “secure”

  • Alerts are ignored or misunderstood

  • No one owns incident response

  • Evidence is never collected

This is how you end up with tenants full of expensive security features that would look great in a demo… and fail completely in a real incident.

Security theatre feels good. Security outcomes save businesses.

Frameworks Help — If You Use Them Properly

Frameworks like Essential Eight, SMB1001, or similar are useful only when they’re treated as outcome checklists, not box‑ticking exercises.

The question shouldn’t be:

“Do we have this control?”

It should be:

“What risk does this reduce, and how do we know it’s working?”

That mindset forces:

  • Validation

  • Testing

  • Monitoring

  • Evidence collection

  • Continuous improvement

In other words: real security.

MSPs: This Is Your Unfair Advantage

For MSPs, outcome‑focused security isn’t just better — it’s a differentiator.

Anyone can resell licences. Anyone can deploy a baseline. Very few can explain, demonstrate, and continuously deliver security outcomes.

If you can show a client:

  • What you’re protecting

  • Why it matters to their business

  • How you’ll know if it fails

  • What happens when it does

…you move from “IT provider” to trusted risk partner.

That’s where long‑term value lives.

Final Thought

Security tools are necessary. They are not sufficient.

If your security story starts and ends with products, dashboards, or licences, you’re missing the point.

Focus on outcomes. Design backwards from real‑world incidents. Measure what matters. Prove it continuously.

Because at the end of the day, the business doesn’t care what tools you deployed.

They care whether they can still operate tomorrow.

AI, Ballistic Missiles, and the Road to the Moon

image

When people get nervous about AI, I often hear the same line: “This is dangerous tech. We should slow it down.”

Fair enough. But history tells us something important here, and it’s worth paying attention to.

One of the most important technologies that put a man on the moon started life as a weapon.

Ballistic missiles were not built for exploration. They were built to deliver destruction over long distances. Cold, deliberate, strategic destruction. Yet the same physics, engineering, and propulsion research behind intercontinental ballistic missiles became the foundation for spaceflight. Without that uncomfortable origin story, the Saturn V never leaves the launch pad, and Neil Armstrong never takes that step.

That doesn’t make missiles good. It makes them dual‑use.

And that’s the lens we should be using when we talk about AI.

Dangerous Origins Don’t Mean Useless Futures

AI didn’t come out of a university lab with a whiteboard and good intentions. Much of the early funding and acceleration came from defence, intelligence, and surveillance use cases. Pattern recognition. Target identification. Signal analysis. Decision support under pressure.

Sound familiar?

Those same capabilities now sit inside Microsoft 365, quietly drafting emails, summarising meetings, analysing spreadsheets, and answering questions that used to burn hours of human effort.

The uncomfortable truth is this: the most powerful tools humans have ever built almost always start life solving hard, often hostile problems. War, competition, scarcity, fear. That’s where money flows fast, constraints are brutal, and innovation accelerates.

AI is no different.

But here’s the mistake people make: they assume that because a technology can be used as a weapon, it will only ever be a weapon.

History says otherwise.

The Moonshot Moment for AI

Once missile technology crossed a certain threshold, its value escaped the battlefield. Suddenly, we weren’t just talking about deterrence. We were talking about satellites, GPS, weather forecasting, global communications, and space exploration.

The same inflection point is happening with AI right now.

We’ve moved from “Can this model do something impressive?” to “How do we embed this capability into everyday work?” That’s the real transition. Not demos. Not hype. Capability.

For businesses, especially SMBs, AI isn’t about replacing humans or unleashing Skynet. It’s about finally getting leverage on the boring, repetitive, soul‑destroying work that drains productivity every single day.

Email triage. Document drafting. Policy writing. Meeting notes. Data analysis. Training. Coaching. Idea generation.

This is the moonshot: not artificial general intelligence, but augmented human intelligence at scale.

But Missiles Are Still Weapons

Now here’s the part too many AI evangelists skip, and it matters.

Missiles didn’t stop being weapons just because they helped us reach the moon.

Even today, the most advanced rockets in the world sit in silos, on submarines, and behind guarded fences. The same technology that launches satellites can still flatten cities.

AI is exactly the same.

Just because we’re using it to improve productivity doesn’t magically make the risks disappear. AI can still be used to manipulate, deceive, automate attacks, leak data, and amplify poor decision‑making at machine speed.

Pretending otherwise is reckless.

This is why governance, guardrails, and education matter more than raw capability. Not bans. Not fear. Not blind adoption. Competence.

The Real Risk Is Not the Tool — It’s the Operator

Most AI failures I see in the real world don’t come from the model. They come from people.

People pasting sensitive data into the wrong tools.
People trusting outputs without understanding limitations.
People automating decisions they don’t actually comprehend.

This isn’t an AI problem. It’s the same problem we’ve always had with powerful tools: we deploy them faster than we train the humans using them.

We didn’t solve missile risk by pretending rockets didn’t exist. We solved it through treaties, controls, oversight, and deep technical understanding.

AI needs the same maturity curve.

Choose Capability Over Panic

So when someone tells me AI is dangerous, my answer is simple: yes, and so was nearly every transformative technology before it.

The question isn’t whether AI can be misused. It absolutely can. The question is whether your organisation will develop the capability to use it well, safely, and deliberately.

Ignoring AI because it scares you doesn’t reduce risk. It increases it. You just outsource the learning curve to attackers, competitors, and less cautious organisations.

Ballistic missiles helped put a man on the moon — and they’re still weapons today. Both truths can exist at the same time.

AI is no different.

The future belongs to the people who understand that tension and choose to master the tool rather than fear it.