Self-Service Password Reset with writeback: the rollout that doesn’t burn your helpdesk

image

SSPR is a box most MSPs tick on day one of a Business Premium tenant and then never look at again. That’s fine until a hybrid customer calls because Karen changed her password on My Sign-Ins, logged into her domain-joined laptop, and got rejected. SSPR without writeback is half a feature. Here’s how to deploy the whole thing properly.

Prerequisites people miss

The obvious ones — an Entra ID P1 license (included in Business Premium) and either Entra Connect Sync or Entra Connect Cloud Sync — aren’t where rollouts die. The misses are:

  • On-prem AD permissions for the sync account. The account running Connect (or the Cloud Sync provisioning agent) needs Reset password, Change password, Write lockoutTime, and Write pwdLastSet on the user OUs. The Connect wizard grants these if you let it; locked-down AD environments often don’t. Writeback fails silently if these are missing.

  • A matching on-prem password policy. Entra enforces its own complexity rules. If your on-prem policy is stricter (minimum length, history, banned words), a user’s new cloud password will be rejected by AD when it writes back, and the user will see a generic error. Align them before you enable, not after.

  • Combined registration actually enabled and enforced. Legacy SSPR-only registration still exists in old tenants. If users register methods for MFA but not SSPR, the reset flow blocks them.

See Microsoft’s writeback concept doc for the full supported-operations list: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sspr-writeback(opens in new window).

Where to configure it

Everything is in the Entra admin centre — no PowerShell required for a standard deploy.

The rollout pattern that works

Don’t flip it on tenant-wide. The pattern that doesn’t generate tickets:

  1. Pilot group of ~10 — IT plus two friendly business users. Scope SSPR to that group only. Verify a reset from My Sign-Ins actually lands in AD (pwdLastSet on the DC is your proof).

  2. Registration campaign to the pilot for 14 days. Force them through combined registration. Watch the Registration report for stragglers.

  3. Broaden by department, not by “All users.” Finance first, then ops, then field staff. Each wave gets the campaign a week before the SSPR scope flips.

  4. Protect the registration step with Conditional Access. Use Register security information as the user action and require MFA (or a Temporary Access Pass for new starters): https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration(opens in new window). Without this, an attacker who phishes a password can register their own MFA method and own the account.

Top pitfalls

  1. Admins can’t use SSPR the same way users can. Privileged roles are locked to strong methods and can’t rely on Security Questions. Test with an admin-tier account before you cut over — and keep a break-glass account that is explicitly excluded from the CA registration policy.

  2. Writeback “works” but the user still can’t log in. Nine times out of ten this is cached credentials on a domain-joined laptop that hasn’t seen a DC since the reset. Tell the user to connect to the corporate network or VPN and lock/unlock. Bake this into your helpdesk script.

  3. Cloud Sync vs Connect Sync confusion. You can run them side-by-side, but writeback must be enabled on whichever one syncs that user’s domain. Audit first — we’ve seen tenants with both running where writeback was enabled on the wrong one and nobody noticed until a reset failed.

Enable it properly once, and SSPR moves from a compliance checkbox to a real helpdesk-deflection tool.

A Cleaner Way to Connect PowerShell to Exchange Online

image

If you still rely on Connect-ExchangeOnline with a username, password, and an MFA prompt, you already know the pain. Scripts break overnight. Scheduled tasks fail when a token expires. Service accounts get flagged by conditional access. And the moment someone enables MFA on the admin account you’ve been quietly using, your automation falls over.

I’ve been written a new script —

https://github.com/directorcia/Office365/blob/master/o365-connect-exo-cert.ps1

with full documentation here:

https://github.com/directorcia/Office365/wiki/Connect-to-Exchange-Online-with-Certificates

— that swaps all of that for certificate-based app authentication. There’s nothing exotic about the underlying approach; Microsoft has supported it for years. What’s been missing is a clean, one-shot way to set it up without spending an afternoon clicking through the Entra portal. That’s what this script gives me, and I think it earns its place in any MSP’s toolkit.

What the Script Actually Does

There are two modes, controlled by switches.

-GenerateLocalCertificate creates a self-signed RSA-2048 certificate in your current user’s certificate store, exports the public key as a .cer file, and optionally exports a password-protected .pfx. By default it’s valid for two years. That’s the local side of the handshake.

-UseCertificateAuth is the everyday mode. You tell it which tenant to connect to — or let it look up the details in a profile map file — and it signs into Exchange Online using that certificate. No password. No browser. No MFA dialog.

The clever bit is the third option: combining -GenerateLocalCertificate with -ProvisionEntraApp -Tenant 'contoso.onmicrosoft.com'. In a single run, the script will generate the local certificate, authenticate to Microsoft Graph via a device-code flow, create the Entra ID app registration if it doesn’t exist, upload the certificate, grant Exchange.ManageAsApp and Application.Read.All with admin consent, create the matching service principal, sign you into Exchange Online to add the app to the Organization Management role group, and save the tenant, app ID, and certificate thumbprint to a JSON profile file so future connections don’t need any of those parameters.

That’s a job that normally takes twenty minutes of clicking, copying GUIDs, and second-guessing whether the right role got assigned. The script does it in about ninety seconds.

Getting Started

If you’re new to certificate auth, the first run is the one that matters. Drop the script onto an admin machine, open PowerShell, and run:

.\o365-connect-exo-cert.ps1 -GenerateLocalCertificate -ProvisionEntraApp -Tenant 'yourtenant.onmicrosoft.com'

You’ll be prompted to sign in twice — once via device code for the Graph permissions (which if you use the –copydevicecodetoclipboard, option will put the required device code straight into the clipboard to paste into the request), then again with Connect-ExchangeOnline so the script can add the app to the role group. Both need a Global Admin account. After that, every future run is just:

.\o365-connect-exo-cert.ps1 -UseCertificateAuth -Tenant 'yourtenant.onmicrosoft.com'

No prompts. No browser. The script reads the tenant, app ID, and thumbprint from o365-exo-cert-auth.json (saved to parent directory), finds the certificate in your local store, builds a signed JWT, and you’re in. One caveat worth flagging: when you’ve just provisioned a brand-new app, give it fifteen to thirty minutes for role assignments to replicate before you try to connect. The script warns about this in its output, but it’s the single most common reason a fresh setup looks broken when it isn’t.

If you’re managing more than one tenant, the profile file is where this really earns its keep. Each provisioning run appends or updates an entry, so you can ask for a connection by -ProfileName, -Tenant, or -Organization and the script picks the right credentials. When several profiles match, it lists them and lets you choose.

Why Certificates Beat Passwords

The security argument is the easy one. A certificate’s private key never leaves the machine that generated it. Nothing crosses the wire that an attacker could intercept and replay. There’s no shared secret to rotate across a team, no admin password sitting in a vault that someone might extract, and no MFA bypass to engineer because the flow doesn’t involve a user account at all.

Permissions are scoped too. The app holds only Exchange.ManageAsApp and read-only access to application metadata. If the certificate is ever compromised, you remove the key credential from the app registration and the access is gone — no password reset required, no impact on any human admin account.

The script enforces TLS 1.2, refuses to assign RBAC if the EXO session has landed in the wrong tenant, warns when the certificate is within thirty days of expiry, and keeps the device-code value off the clipboard by default to avoid leaks on RDP or shared sessions. Small things, but they add up.

Why It’s a Win for Automation

Certificate auth is what makes unattended Exchange Online work actually unattended. A scheduled task running at 2 a.m. doesn’t have a human to click “Approve” on an MFA prompt. With this approach, you point Task Scheduler at the script with -noprompt, pass the tenant, and walk away.

For an MSP, that becomes a per-tenant capability rather than a per-admin one. One profile file, one shared script, separate certificates per tenant or per admin machine — and now mailbox audits, distribution group cleanup, shared mailbox provisioning, and any of the other recurring chores you keep meaning to automate can run on a timer instead of waiting for a quiet Friday afternoon. Pair it with a Power Automate flow or a daily Copilot summary in Teams, and you’ve got reporting that lands in front of the right people without anyone signing in.

Where I’d Take It Next

If you’ve never moved off interactive sign-in for Exchange Online, this is the path I’d take. Spend half an hour standing it up against a test tenant. Get comfortable with the profile file. Then start moving your scheduled work over, one job at a time. The shift from “who’s signing in?” to “which certificate is presenting itself?” is a quiet one, but once your automation stops breaking every time an admin’s MFA settings change, you won’t go back.

Purpose Is Not a Strategy (And MSPs Are Paying the Price)

image

You didn’t start your MSP just to make money.

There was something more. A problem you wanted to solve. A frustration you saw in the market. A sense that “IT could be done better” for small businesses that kept being ignored or overcharged.

That purpose matters. It still does.

But here’s the uncomfortable truth many MSP owners don’t like admitting:

Purpose without a plan is just a story you tell yourself.

I see plenty of MSPs who care deeply about their clients, their staff, and “doing the right thing”… yet wonder why growth has stalled, margins are thin, and every year feels harder than the last.

Caring is not the problem. Lack of focus is.

When Good Intentions Don’t Move the Needle

Most MSPs I talk to aren’t lazy or incompetent. They’re overloaded.

They’re saying yes to every request, every new tool, every vendor promise, and every “quick opportunity” that pops up. Slowly, almost invisibly, their original purpose gets diluted by noise.

Here’s what that looks like in the real world:

  • Offering ten different service bundles because “every client is different”

  • Chasing the latest security product while last year’s one is barely implemented

  • Talking about standardisation, but never enforcing it

  • Claiming to be “strategic” while the business runs on reactive tickets

None of this is malicious. It’s what happens when there’s no clear plan anchoring decisions.

You care about security, but do you have a defined baseline every client must meet?

You care about client outcomes, but can you clearly articulate the outcomes you deliver repeatedly?

You care about your team, but is the business designed to support them—or exhaust them?

Focus Is the Real Competitive Advantage

In the SMB market, MSPs don’t win by being everything. They win by being consistent.

The MSPs making real progress right now aren’t necessarily smarter or bigger. They’ve simply decided what matters—and stopped apologising for it.

They draw clear lines:

  • This is our core stack

  • These are our minimum standards

  • This is how we onboard, secure, and support clients

  • This is what we don’t do

That focus creates momentum.

Technicians know what “done properly” looks like. Clients know what they’re buying. Sales conversations become simpler. Tool sprawl reduces. Security improves because execution improves.

Most importantly, energy stops leaking.

Every “yes” you don’t think through properly costs far more than the revenue it brings in.

Turn Purpose Into Something That Actually Scales

If your MSP purpose is more than a feel‑good origin story, it needs structure.

Ask yourself three hard questions:

  1. What problem do we solve better than most MSPs our size?
  2. What standards are we no longer willing to compromise on—even if it costs us a client?
  3. What would we stop doing next quarter if we truly backed our own strategy?

None of these require new tools. They require leadership decisions.

Purpose is the why.
Planning is the how.
Discipline is the difference.

The Real Takeaway

You can care deeply and still stay stuck.

Progress doesn’t come from passion alone—it comes from choosing fewer things and doing them consistently well.

If your MSP feels busy but fragile, successful but stretched, it’s not because you’ve lost your purpose.

It’s because it’s time to turn that purpose into a plan you’re willing to defend.

Start there. Everything else gets easier once you do.

Your Conditional Access Is Stuck in 2018

image

You get a phone call from a client one Sunday morning in February. One of their bookkeepers had clicked an invoice link the previous Friday afternoon, signed in like normal, and gone home for the weekend. By Monday, the attacker had set up an inbox rule, watched a fortnight of email traffic, and sent a payment-redirect note to a supplier — from the bookkeeper’s actual mailbox. Eighty thousand dollars walked out the door before anyone noticed the wire details had quietly changed.

The tenant had MFA enforced. It had a Conditional Access policy. It had cyber insurance, renewed in January on the strength of those two things. None of that mattered.

The attack moved. The configuration didn’t.

Adversary-in-the-middle phishing kits don’t try to beat the MFA prompt anymore. They wait for the user to complete it, then steal the session token and replay it from somewhere else. Microsoft’s threat intel team disclosed an April campaign that hit thirty-five thousand users across thirteen thousand organisations in twenty-six countries — a single month, a single operator. Every one of those users had MFA. None of them had session controls tuned to actually defend the session.

This is the bit MSPs need to sit with. Conditional Access in Entra was never built as an MFA tickbox. It is the session control surface — the place where you decide what a signed-in user can do, from where, on what device, for how long. The grant and session controls in that same blade — the ones most SMB tenants have never opened — are what break this attack. We have spent five years building a defence for 2018 and leaving it deployed in 2026.

Four switches, all in the same blade

There are four controls inside Conditional Access that meaningfully change the outcome of a token theft, and most Business Premium tenants pay for all of them and use none.

  • Sign-In Frequency, set deliberately rather than left at its sliding ninety-day default, collapses the lifetime of a stolen token. Most tenants I look at have it set backwards — managed users get prompted constantly while unmanaged sessions ride for weeks.
  • Require-compliant-device on Exchange Online forces the attacker’s browser session to fail at the grant, not the prompt.
  • Phishing-resistant authentication strength — passkeys, FIDO2, Windows Hello — closes off the credential path to begin with.
  • Token Protection, even in report-only on Windows native apps, gives you the telemetry to spot a session being replayed from a country your user has never visited.

None of this is theoretical. Microsoft auto-rolled Conditional Access into more than half a million tenants in late 2023 specifically because tenants were not configuring it themselves. That auto-rollout sets the floor. The four controls above sit above the floor, and they are the ones that change the renewal conversation with your insurer.

The unit economics finally work

The honest reason most MSPs haven’t retuned their CA baseline is that per-tenant identity work used to be uneconomic. That changed. With GDAP and Microsoft Lighthouse, an MSP can review CA policy, push report-only changes, and watch sign-in telemetry across every client tenant from one pane. Pair that with a Loop page or a Teams channel for your security pod and the review cadence stops being a heroics exercise.

The bookkeeper followed her training to the letter. What let her down was a tenant configured for the threat landscape we had four years ago. When the next breach lands in one of your tenants, it will not be the MFA prompt that failed. It will be the session controls nobody touched. That is where the work is now.

Windows Hello for Business: Pick Cloud Kerberos Trust and Move On

image

Every few weeks I get a question from an MSP engineer that starts with some version of “we’re about to roll out Windows Hello for Business — key trust or cloud trust?” My answer has been the same for a couple of years now, but the question keeps coming because the documentation is sprawling and the old hybrid PKI diagrams still haunt everyone who deployed WHfB before 2022. If you have a hybrid Active Directory and a Business Premium tenant, you should be on cloud Kerberos trust. Full stop. Everything else is legacy baggage.

The prerequisites people still miss

Microsoft’s own planning guide is the source of truth, but two prereqs catch MSPs out every time.

First, domain controllers. Cloud Kerberos trust needs Windows Server 2016 or later DCs, fully patched, and you need enough read-write DCs in every AD site where users will authenticate. If your branch office has one creaky 2012 R2 box left, the sign-in will fail in ways that look like network issues and waste a day of your life.

Second, Microsoft Entra Kerberos has to be explicitly enabled against the on-prem domain. It’s not on by default. Skip it and users will provision a PIN happily, then fail to reach on-prem file shares the first time they try. The cloud Kerberos trust deployment guide walks through enabling it.

Where to configure it

For greenfield Autopilot tenants, the fastest path is the Intune tenant-wide enrolment policy at Intune admin center → Devices → Enrolment → Windows → Windows Hello for Business. Set it to Enabled and configure the defaults there. That covers OOBE.

For everything else, build an explicit Account Protection policy at Intune admin center → Endpoint security → Account protection → Create Policy → Windows → Account protection → Windows Hello for Business. This is the one you target at device groups for staged rollout. Microsoft’s tenant-wide policy guide explains the precedence rules; read it before you layer policies.

A rollout pattern that survives contact with users

I run three rings and I don’t apologise for how boring it looks.

Ring 1: five to ten IT-adjacent devices for two weeks. You’re looking for PIN provisioning completion and on-prem resource access — not for smiles.

Ring 2: one full business unit, minimum fifty devices, two to three weeks. This is where you catch VPN quirks, smartcard reader conflicts, and the one shared PC nobody told you about.

Ring 3: the rest of the fleet, staged over a fortnight by device group, not by user.

Stage by device, not by user, because Windows Hello is a per-device-per-user credential. Chasing user groups creates a weird matrix where someone’s laptop prompts for a PIN but their desktop doesn’t, and the helpdesk gets blamed for inconsistency.

The pitfalls that burn you

Rolling back is worse than rolling forward. Disabling the policy doesn’t remove provisioned PINs; it just stops new ones. Plan the forward path before you enable it.

Don’t mix trust types. If you have leftover key trust policy from an old deployment, retire it before enabling cloud Kerberos trust on the same fleet. The hybrid key trust guide is still published, and Microsoft explicitly recommends against key trust for new deployments — pay attention to that.

Shared and kiosk devices need explicit exclusions. WHfB binds a credential to a user-device pair, which is exactly wrong for a front-desk PC logged in as five different people a day. Use Intune filters to carve those devices out of the policy.

Get the prerequisites right, pick cloud Kerberos trust, ring it, and Windows Hello becomes the quietest part of your security stack. Which is what you want.

Friction is the problem

image

Here’s the uncomfortable truth most MSPs and consultants won’t admit: the problem with sales isn’t lead volume, pricing, or even competition. It’s friction. Too many steps. Too much chasing. Too many maybes clogging up your calendar and your head.

If you’ve ever found yourself following up with someone who “just needs a bit more time”, you already know how this ends. Ghosted inbox. Awkward check‑in. Energy wasted on people who were never going to buy in the first place.

There is a simpler way to sell. Not a hack. Not a funnel with seventeen moving parts. Just a cleaner path for the right buyer to move from recognising a problem to committing to a solution.

It starts with clarity.

Make the decision easy, not emotional

Most sales calls exist because the offer isn’t clear enough on its own. When pricing, scope, outcomes, and expectations are fuzzy, people feel unsafe deciding. So they ask for a call. Or another call. Or “one last question”.

A well‑constructed offer document removes that uncertainty. It spells out exactly who it’s for, what changes, what it costs, and what happens next. The wrong people self‑select out. The right people don’t need convincing.

If someone can’t say yes after reading a clear, specific offer, they were never your client anyway.

This is how you sell without talking.

Attention beats persuasion every time

Even great offers fail when there’s no urgency. Not fake scarcity. Real focus.

When there’s no timeframe to decide, people default to delay. Not because they don’t want the outcome — but because there’s no cost to waiting. That’s not a motivation problem. It’s a prioritisation one.

A short, defined buying window forces a decision. It compresses attention. It moves the offer from the “someday” pile into the “do I act now or not at all?” category.

And here’s the key: a deadline doesn’t pressure the buyer. It respects their time. They either act, or they opt out cleanly. No limbo. No follow‑ups. No chasing.

You can run this every week if you want. Same offer. Same structure. New group of buyers. Simple, repeatable, predictable.

Demand is built before you sell

If your offer relies on clever copy to create desire, you’ve already lost. Demand doesn’t start on launch day. It’s built in advance, through relevance and trust.

This is where most MSPs get it backwards. They build services first, then hope the market catches up.

Instead, you grow an audience around a problem you understand deeply. You share insight. Opinions. Practical guidance. Over time, people stop seeing you as “a provider” and start seeing you as the obvious next step.

So when you make an offer, it doesn’t feel like selling. It feels like progression.

That’s how you scale. Not with bigger funnels or louder campaigns, but with a warmer market that’s already aligned with how you think and how you work.

Less noise. Better clients.

The goal isn’t more leads. It’s fewer, better decisions.

No hand‑holding prospects. No endless objections. No paying a percentage just to get work you could close yourself. No energy drain from people who aren’t serious.

Just a clean system that respects your time and your buyer’s autonomy.

The right people don’t need chasing. They need clarity, focus, and a reason to act.

Build that, and sales stops being something you dread — and starts being something that just works.

Intune Filters vs Assignment Groups: Stop Treating Them as Interchangeable

image

If your Intune estate has grown past a couple of hundred devices, you’ve probably built a forest of dynamic groups that only you understand. You don’t need another group. You need a filter. Here’s where each one earns its keep, and where MSPs keep getting the split wrong.

The mental model

Groups answer who the policy targets. Filters answer which subset of that assignment it actually applies to at evaluation time. A group is resolved at assignment and refreshed on Entra’s schedule. A filter is evaluated per device, per policy, at the point of applicability. That timing difference is the entire reason filters exist — and the reason swapping one for the other silently changes behaviour.

Use groups for ownership of the assignment (department, site, client tenant, pilot ring). Use filters for device traits that change underneath you: OS version, model, enrollment profile, personal vs corporate, join type.

Prerequisites people miss

  • Filters only work on managed devices and managed apps — the supported workload matrix matters. Not every policy type honours filters, and app assignment filters for MAM are a different object from device assignment filters. Check the reference before assuming your policy can be filtered.

  • Dynamic device groups require at least one Entra ID P1 licence in the tenant. Business Premium covers you, but confirm before promising dynamic membership to an M365 Standard client.

  • The “All users” and “All devices” virtual groups bypass normal targeting logic. If a client’s environment feels “haunted”, check whether a legacy assignment is hitting All devices with no filter.

Where to configure

In the Intune admin center, filters live under Tenant administration → Filters. Build the rule, pick the platform, and save — the filter itself has no targets. You apply it at assignment time on any supported policy (Devices → Configuration → your profile → Assignments → Edit filter).

Groups are managed in the same console under Groups, but remember these are Entra ID security groups — any change you make is tenant-wide, not Intune-only.

The rollout pattern that actually works

  1. Ring by group, scope by filter. Three device groups (Pilot, Early, Broad) assigned by user or device attribute. Apply the same policy to all three with different filters (e.g. deviceOwnership -eq "Corporate" plus osVersion -startsWith "10.0.22").

  2. Exclude filters beat exclusion groups. If you’re excluding kiosks from a CA-backed compliance policy, a filter keyed on enrollmentProfileName is faster to audit than a stale exclusion group nobody refreshes.

  3. Name everything for future-you. FLT-Win11-Corp-NotKiosk beats Filter1. Same for groups: prefix by purpose (INT- for Intune-only, SEC- for CA), include platform, include intent.

  4. Test in report-only. Every new filter goes onto one profile assigned to a lab group first. Confirm the Assignment status report matches expectation before widening.

The pitfalls that will bite you

  • Filter evaluation is not group membership. A filter excluding “personal” devices won’t retroactively remove a policy from a device that was previously “corporate” until the device checks in and the assignment re-evaluates. Plan for the delay during ownership changes.

  • Negation logic is deceptively literal. -notEquals treats a null property as “not equal”, so filters on sparsely populated properties (custom enrollment profile names, model on older hardware) can match devices you didn’t intend. Test with -eq plus include/exclude to lock it down.

  • Overlapping filters on the same assignment don’t AND. If you add a filter and also use include/exclude groups, precedence rules apply — exclude always wins, then filters, then includes. Map this out before complaining about “Intune not applying my policy.”

References

Experience builds ideas. Insecurity borrows them.

image

There’s a clear line between people who are doing the work and people who are just talking about it.

You don’t need a title or a following to spot the difference. You see it in how they speak, not how loudly.

People with real experience tend to build their own thinking. It’s imperfect, occasionally blunt, and often inconvenient. It comes from trying things, getting them wrong, adjusting, and doing it again. Their ideas are shaped by reality.

Everyone else tends to borrow.

They echo whatever message is trending. They swap a few words, add a diagram, and pass it off as insight. Same advice, different branding. No scars. No evidence. No ownership.

Doing the work changes your language

When you’ve actually implemented something—whether that’s a security framework, a new service offering, or AI inside a business—you stop speaking in absolutes.

You don’t say “this will change everything”.
You say “this worked here, under these conditions”.

You don’t promise miracles. You talk about trade-offs.

That shift only happens when you’ve been responsible for the outcome. When you’ve had to answer the awkward questions. When you’ve watched users ignore the thing that looked perfect in a slide deck.

That’s why experience produces original thinking. It can’t help it.

The AI gold rush has exposed the gap

AI has made this divide painfully obvious.

Right now, it’s easy to generate confident-sounding content without having touched a real deployment. Tools can produce posts, prompts, courses, and “frameworks” at scale. The barrier to publishing has collapsed.

The barrier to credibility hasn’t.

Most AI commentary falls into the same bucket:

  • Vague promises

  • Recycled examples

  • Zero mention of friction

Very little of it answers the questions businesses actually ask:

  • Why didn’t staff use it?

  • What broke when permissions were wrong?

  • Where did the time savings not appear?

  • What did we stop doing to make this work?

Those answers only come from hands-on work. You can’t fake them convincingly for long.

MSPs live or die on credibility

This matters even more for MSPs and IT pros.

Our job isn’t to repeat vendor messaging. It’s to interpret reality for customers. That means filtering hype, testing claims, and sometimes saying “not yet” or “not like that”.

The strongest MSPs I know don’t rush to publish hot takes. They pilot first. Internally. With a handful of customers. They watch what actually happens, then they form a point of view.

When they speak, it sounds different. Less polished. More grounded. More useful.

That’s not an accident. That’s earned.

Borrowing ideas is safe. Creating them isn’t.

Borrowing someone else’s thinking feels low-risk. If it doesn’t land, you can shrug and move on. You were just sharing something interesting.

Creating your own position is riskier. It invites disagreement. It exposes what you don’t know yet. It ties your name to an outcome.

But that’s also where authority comes from.

Not from being first. Not from being loudest. From being responsible.

Ask yourself the harder question

Before publishing, presenting, or advising, it’s worth pausing and asking:

Am I speaking from repetition, or from experience?

Have I tested this, or just read about it?

Would I still hold this view if the tool, platform, or trend disappeared tomorrow?

If the answer is uncomfortable, that’s probably a signal—not to stop sharing, but to go deeper. To build something. To test something. To get closer to the work.

Because in the long run, people don’t follow confidence. They follow clarity. And clarity comes from contact with reality, not from copying what’s already out there.

That’s how real ideas are formed. And that’s what makes them worth listening to.