Here's how to think about what you're actually evaluating.

The break-fix model (what managed IT replaced)

Before managed IT became the norm, most small businesses hired IT help on an as-needed basis: something breaks, you call someone, they fix it and send a bill. It's simple, but it has obvious problems. The provider has no financial incentive to prevent problems — in fact, more problems means more revenue. And you have no way to predict what IT will cost in a given month.

What "managed" is supposed to mean

The core promise of managed IT is proactive management: your IT provider is responsible for keeping your environment running, not just responding when it breaks. That means monitoring, patching, and addressing issues before they become outages — as well as handling the reactive support when something does go wrong.

The pricing model reflects this. Flat-rate managed IT charges a predictable monthly fee based on your team size and infrastructure, not by the hour. This aligns incentives: the provider succeeds financially when your systems stay healthy, not when they break.

Where the variation is

Not all managed IT providers work this way in practice. Some charge a flat fee but still think reactively — they respond to tickets, but they're not proactively monitoring your environment or getting ahead of problems. Others operate at the full end of the spectrum, functioning as an embedded IT department that attends to your infrastructure continuously.

The questions that separate the two:

Is someone actively monitoring your environment, or just waiting for you to call? Real monitoring catches problems — a failing drive, a server running out of disk space, an anomalous login — before they cause an outage.

Do they document your environment? A managed IT provider who doesn't maintain documentation of your systems is not managing them; they're reacting to them. Good documentation means faster resolution, easier transitions, and fewer "how did we have this set up?" conversations.

Are they making recommendations? If your IT provider never proactively suggests improvements or flags aging hardware before it fails, they're not thinking ahead. A genuine partner surfaces things you don't know to ask about.

Does the billing model discourage you from asking for help? If you hesitate to call because you're worried about the cost, the model is working against you. Flat-rate support should remove that friction entirely.

What to look for

When evaluating a managed IT provider, ask specifically about their monitoring and alerting practices, how they handle documentation, and what their typical communication looks like outside of support tickets. The answers will tell you whether you're getting a proactive partner or a sophisticated help desk.

Here's a practical way to think about it.

Email is for external communication and formal records

If you're communicating with a client, a vendor, a subcontractor, or anyone outside your organization, email is almost always right. It creates a clear record, it works with any inbox, and there's no expectation that the other person has any particular software.

Email also makes sense internally when you need a paper trail — sending a proposal for internal review, notifying the team of a policy change, or communicating something that needs to be archived and searchable later.

Teams is for internal collaboration that doesn't need to be a meeting

The Teams sweet spot is conversation that would otherwise result in a meeting or a long email thread — working through a question, getting quick input on a decision, coordinating on an active project. It's lower overhead than a meeting and easier to follow than a reply-all chain.

The channel structure in Teams also lets you keep project conversations organized without clogging up anyone's inbox. A project channel is visible to everyone on that project, searchable, and persistent — something a group email thread never quite manages.

The part that trips people up

Most teams struggle not with the tools themselves, but with consistency. When half the team uses Teams for everything and the other half lives in email, you get fragmented communication and people missing things.

It helps to establish a simple default: Teams for internal collaboration, email for anything external or formal. You don't need a long policy — just a shared understanding that people can actually stick to.

One thing worth knowing

Microsoft 365 stores Teams messages separately from email, and both have retention and backup implications. If your firm is subject to any records retention requirements or compliance obligations, how you use these tools matters beyond just convenience. That's worth a conversation with your IT team if you haven't had it.

Multi-factor authentication stops most of these attacks cold. And yet a lot of small businesses still haven't fully deployed it, often because they've heard it's disruptive or because it got deferred during a busy period and never revisited.

What MFA actually does

MFA requires something you know (your password) plus something you have (typically your phone) to sign in. If someone steals or guesses your password, they still can't access your account without also having your phone and approving the sign-in.

This is meaningful protection. Microsoft's own data suggests that MFA blocks over 99% of automated credential-stuffing attacks.

What it doesn't do

MFA is not a complete security solution. It doesn't protect you against phishing attacks where you're tricked into approving a fraudulent sign-in prompt — an increasingly common attack called MFA fatigue or prompt bombing. It doesn't protect against malware on your device. It's one layer, not the whole answer.

That said, it's the most effective single security control available for cloud accounts, and it's the floor, not the ceiling.

The deployment concern is usually overstated

Most resistance to MFA comes from anticipating disruption that doesn't materialize. Once deployed, Microsoft Authenticator and similar apps become a quick and familiar habit. The average business user needs to approve a prompt a handful of times per week, usually on a device they already have in their hand.

The disruption risk is real during rollout — particularly for users with older devices or those who frequently change phones. That's the part that warrants some planning. Rolling it out account by account, with a brief orientation for each user, is less chaotic than a firm-wide cutover with no warning.

In Microsoft 365

Conditional Access policies in Microsoft 365 give you control over when MFA is required — you can require it for all logins, only when signing in from outside the office network, only for certain applications, and so on. Getting these policies right is worth doing carefully; set too broadly, they create unnecessary friction; set too narrowly, they leave gaps.

If your organization hasn't deployed MFA yet, it's the highest-ROI security action available to you right now. If you've deployed it but aren't sure your Conditional Access policies are configured correctly, that's worth a review.

Neither answer is right for every firm. Here's how to think about the choice.

When shared drives still make sense

A traditional file server or mapped drive works well when your team's workflow is simple and stable — everyone accesses the same folder structure, files are mostly project-based, and nobody needs to collaborate on documents in real time.

If that describes your firm and your current setup works, there's no urgent reason to move. The migration overhead and learning curve of SharePoint may not be worth it.

When SharePoint is genuinely better

SharePoint's advantages become real in a few specific situations:

Remote and hybrid work. SharePoint files are accessible from any device without a VPN. For firms with hybrid teams or people who work from multiple locations, this removes real friction.

Document collaboration. When multiple people need to work on the same document, SharePoint with co-authoring is significantly better than a shared drive where someone inevitably has the file locked.

Integration with Teams. Each Teams channel has a SharePoint folder behind it. If you're using Teams for project communication, having project files in the same structure makes sense.

Permissions complexity. SharePoint's permissions model is more granular than most file servers. If you need different access levels for different projects or client files, SharePoint handles this better.

When SharePoint won't work

Some applications simply can't use SharePoint as a live data location. Autodesk Revit is the most common example in professional services firms — it requires files to be on a local or mapped network drive, and attempting to work with Revit models stored directly in SharePoint causes file corruption and sync conflicts. The same is true of several other design and database applications that hold files open for extended periods.

If Revit or similar software is central to how your team works, a shared drive (or a hybrid approach where project work stays on a file server while other documents move to SharePoint) is not optional — it's the only configuration that works reliably.

The catch with SharePoint

SharePoint requires governance to work. "Just put the files in SharePoint" is not a migration strategy. Without a clear folder structure, naming conventions, and some training, it degrades into something worse than the shared drive you left.

Firms that have bad SharePoint experiences usually had one of two problems: they migrated without structuring it first, or they let too many people create sites and folders without any coordination.

The good news is that the governance overhead isn't enormous — it just has to happen before the migration, not after.

A practical approach

If you're evaluating a move, start by asking how much of your work is truly collaborative versus individual. If most of your work is one person on one file, the advantages of SharePoint are smaller. If your team regularly hands documents back and forth or needs simultaneous access, the benefits are more immediate.

Either way, a migration is worth planning deliberately rather than treating as a simple lift-and-shift.

The convenience pitch is obvious. The security and operational arguments are worth understanding separately.

What it means for your team

Without SSO, every new application means a new account. People reuse passwords because remembering unique ones for a dozen tools isn't realistic. They create accounts with personal email addresses when work email is too cumbersome. They stay logged in to things on shared machines because signing back in is friction.

SSO removes most of this. When everything authenticates through Microsoft 365, password reuse stops being a problem for those applications — there's only one credential to protect. And because MFA is enforced at the Microsoft 365 level, it extends automatically to every connected app without separate configuration for each.

The experience for your team is simpler: they sign in once in the morning and everything they need is accessible. Most people don't think of this as "security infrastructure" — they just notice that work is a little less annoying.

What it means for offboarding

This is where SSO delivers its most underappreciated value for small businesses.

When someone leaves your organization, the critical question is: what did they have access to, and has all of it been revoked? Without SSO, the answer usually involves a manual checklist — email, file server, project management tool, accounting software, HR system, client portal, and anything else they may have set up on their own. Something almost always gets missed.

With SSO, disabling a Microsoft 365 account immediately removes access to everything connected to it. One action, done in minutes, covers the full scope of what that person could reach. There's no checklist to run, no risk of forgetting an application they set up six months ago.

For a small business where IT isn't someone's full-time job, this matters. The likelihood of a clean, complete offboarding is much higher when it's a single switch rather than a process that has to be executed perfectly from memory.

What to look for when evaluating software

Most modern SaaS applications support SSO through a standard called SAML or through Microsoft's identity platform directly. When you're evaluating new software, SSO support is worth checking — specifically whether it's available on the plan you'd actually be buying, since some vendors restrict SSO to higher pricing tiers.

Applications that don't support SSO aren't necessarily disqualifying, but they represent a gap in your access management. Knowing which tools fall outside your SSO umbrella is useful both for security reviews and for offboarding checklists.

The administrative side

In Microsoft 365, SSO connections to third-party apps are managed through Azure Active Directory (now called Microsoft Entra ID). Setting up a new integration typically takes minutes and can be done by whoever manages your Microsoft 365 tenant. Once connected, access grants and revocations happen automatically whenever accounts are provisioned or deprovisioned.

If your organization is running on Microsoft 365 but hasn't connected your other software to it, that's a low-effort change with meaningful operational upside.

The reason it's actually more secure has to do with where the credential lives — not how complex it is.

The problem with passwords

When you sign in to Windows with your Microsoft account password, that password is sent to Microsoft's servers to be verified. This creates attack surface: the password travels over a network, it's stored somewhere remotely, and if Microsoft's infrastructure is ever compromised — or if the same password is reused somewhere else that gets breached — your account is at risk.

More practically, passwords can be stolen through phishing, keyloggers, or credential stuffing attacks using passwords leaked from other services.

What Windows Hello does differently

Windows Hello stores your credential — whether it's a PIN, fingerprint, or face scan — directly on the device, in a dedicated hardware chip called the Trusted Platform Module (TPM). The credential never leaves your machine. When you sign in, Windows verifies your identity locally; nothing is transmitted to Microsoft's servers for that verification step.

This means if an attacker steals your PIN, it's useless to them without also physically having your device. You can't use someone's PIN to sign in remotely or on a different machine the way you can with a stolen password.

Why this matters in practice

The most common way accounts get compromised isn't a targeted attack on you specifically — it's automated attacks using credentials harvested from unrelated data breaches. A leaked password from a breached website gets tried against email accounts, Microsoft accounts, bank logins. Windows Hello breaks this entirely: your PIN works only on your device, so a credential breach somewhere else can't be used against your Windows login.

The PIN length is almost beside the point. A four-digit PIN that's hardware-bound to one device is harder to exploit at scale than a twelve-character password that travels over the network.

Biometrics are the same idea

Fingerprint and face recognition in Windows Hello work on the same principle. The biometric template is stored in the TPM and never leaves the device. This is worth knowing if you've had concerns about Microsoft storing a scan of your face somewhere — they don't. The verification happens locally.

If your hardware supports it, fingerprint or face login is worth enabling. The combination of local credential storage and the convenience of not typing anything at all is one of the better security improvements available with no real tradeoff.

Microsoft does an excellent job of protecting your data against things on their end — hardware failures, datacenter outages, regional disruptions. Your email and files are replicated, redundant, and highly available. That's real and it matters.

But it doesn't protect you against the things that actually cause data loss for small businesses.

What Microsoft 365 retention actually does

Microsoft 365 includes retention policies and a recycle bin, which are useful. Deleted emails and files sit in a recoverable state for a period of time — typically 30 to 93 days depending on your license tier and settings.

After that window closes, the data is gone. Microsoft's infrastructure is working exactly as designed.

What it doesn't protect against

Accidental deletion. Someone deletes a project folder they shouldn't have. If it's caught within the retention window, fine. If it's not caught for three months, you're in trouble.

Ransomware. Ransomware increasingly targets cloud storage specifically because it syncs so efficiently. If your OneDrive syncs an encrypted file library to Microsoft's servers, that encrypted version is what gets retained.

Employee departure. When an employee account is deprovisioned, the process matters. If it's done carelessly, data associated with that account can be lost before anyone realizes what was in it.

Malicious deletion. A departing employee — or an attacker with compromised credentials — who systematically deletes files can cause significant damage within the retention window.

What a proper backup looks like

A proper Microsoft 365 backup solution takes independent, point-in-time snapshots of your Exchange, SharePoint, OneDrive, and Teams data — stored separately from Microsoft's infrastructure — so you have recovery options outside their retention window and outside their control.

This isn't an edge case product. It's a standard part of a well-managed Microsoft 365 environment, and most organizations don't have it configured correctly or at all.

If you're not sure what your current backup situation looks like, it's worth finding out before you need it.

This approach makes sense as a line-item decision and usually doesn't make sense as a business decision. Here's why the calculus is more complicated than it looks.

The home office problem

Hybrid and remote work made the home office setup a real variable in employee productivity — and a real variable in your security posture. Someone working from a poorly configured home network on a personal machine represents a meaningfully different risk profile than the same person working from a managed device on a monitored office network.

The equipment question and the security question are connected. A company-owned, company-managed laptop that an employee takes home is an extension of your managed environment. A personal machine running personal software that also handles client files is not.

This doesn't mean you need to control everything. It means you should have a clear policy about what work happens on managed devices, and ideally make those devices good enough that people actually want to use them rather than defaulting to personal hardware.

Peripherals are worth a budget line

Keyboards, mice, monitors, and headsets are where people actually spend their workday. The difference between a poor keyboard and a decent one is felt across every email, every document, every hour of work. The aggregate productivity cost of bad peripherals is real and almost never shows up anywhere in a budget discussion.

A practical approach that works well: give employees a peripherals budget — $200 to $400 is a reasonable range — and let them spend it on whatever they actually want to use. People have strong preferences about keyboards and mice, and letting them choose what they're comfortable with produces better outcomes than standardizing on something mediocre. Most people will spend the budget wisely; the occasional employee who buys something extravagant will still be working on their preferred setup.

This also solves the home office problem neatly for peripherals. A monitor and keyboard they purchased with company funds and use for work is documented, covered by your expense policy, and clearly in scope for the work environment you're managing.

Managed vs. bring-your-own-device

The cleaner your device management story is, the more flexibility you can offer employees without increasing risk. If every company-issued device is enrolled in Microsoft Intune and has a known configuration baseline, you can be relaxed about where people work and what they connect to — because you have visibility and control regardless.

BYOD (bring your own device) is workable but requires more careful policy design. The main risks are data leakage (company files on personal devices that aren't managed), credential exposure (personal machines with weaker security standards accessing company accounts), and the offboarding gap (ensuring company data is fully removed from a personal device when someone leaves).

If you're going to allow BYOD, Microsoft's app protection policies in Intune can apply security controls to individual applications without requiring full device management — a reasonable middle ground for personal phones accessing company email, for instance.

The replacement cycle question

Equipment that's too old creates a slow, diffuse productivity drag that rarely gets attributed to the hardware. A four-year-old laptop running the latest Windows and Microsoft 365 apps is typically sluggish in ways that are frustrating but hard to quantify. People work around it, the complaints become background noise, and the cost never surfaces clearly on a spreadsheet.

A three-year replacement cycle for primary workstations is a reasonable standard for most businesses. Machines that come off the primary rotation can often serve a second life for lighter use cases. When hardware is managed and documented, the replacement cycle becomes a planned budget item rather than an emergency response to a failure.