In a previous post about the adjacencies to the MDR market, I laid out a framework for how MDR needs to evolve beyond alert triage. The basic idea was that future MDR should not just be “EDR alerts plus analysts.” It should become the control plane for cybersecurity operations and cyber risk reduction.
This post goes one level deeper. If MDR is going to become that control plane, what capabilities actually need to sit closest to the operating loop? The strongest extensions are the ones that help MDR understand what exists, what is exposed, what telemetry is missing, what response should happen, and whether risk actually went down.
Asset And Control Coverage
This is the starting point. MDR cannot protect an environment it does not understand, so the provider needs to know:
What exists?
What is unmanaged?
What lacks EDR coverage?
What lacks vulnerability scanning?
What logs are missing?
Which assets are business-critical?
Which controls are present, absent, or failing?
Asset context turns MDR from generic alert review into prioritized operations. An alert on a test machine is not the same as an alert on a domain controller, cloud control-plane asset, payment system, build server, or executive endpoint. An exposed vulnerability on an internet-facing revenue system is not the same as the same CVE on a low-value internal host.
The future MDR has to understand this context automatically in a dynamic envirionment.
Exposure And CTEM
This is probably the most important adjacency. Classic MDR waits for something to fire. Exposure management asks what can be attacked before the alert exists.
The future MDR should know:
What is exploitable?
What is internet-facing?
What is business-critical?
What is currently being targeted?
What attack paths exist?
What should be fixed first?
Which exposures actually got closed?
This is what moves MDR from reactive monitoring to proactive risk reduction. The important distinction is that this cannot just be scanner reporting. Vulnerability management becomes an MDR extension only when it is tied to exploitability, asset criticality, identity paths, observed threat activity, and actual remediation workflow.
SIEM And Data Quality
MDR is only as good as the data it can use. That makes SIEM operations and data quality core to the future model, even if the MDR provider does not own the SIEM product.
The provider should know:
Are the right logs ingested?
Are important sources missing?
Are fields normalized?
Are detections using the right data?
Is retention sufficient?
Is query performance good enough for investigation?
Is SIEM cost being optimized?
This becomes more important as AI changes the interface to the SOC. If AI becomes the primary user of security data, the SIEM UI may matter less, but the quality, structure, accessibility, and completeness of the data matter more.
Cloud And Identity Posture
Modern attack paths increasingly run through identity, SaaS, cloud entitlements, workload permissions, and configuration mistakes. That means cloud and identity posture are not optional context for serious MDR.
The future MDR should understand:
Who can access what?
Which identities are overprivileged?
Which accounts are risky or stale?
Which cloud paths create attack chains?
Which workloads are exposed?
Which posture issues make detection or containment harder?
Without this context, MDR sees too little. It may detect a suspicious event, but miss the path that made the event possible.
Response Orchestration
The MDR has to respond faster than human-speed response, but safely. The system should be able to:
Isolate an endpoint
Disable or step-up an identity
Block an indicator
Remove malicious artifacts
Open and route tickets
Trigger patching or remediation workflows
Escalate to IR
Prove that the action happened
The word “safely” matters. MDR automation cannot become a blind SOAR playbook that breaks production. The provider needs policy, approvals, rollback paths, asset criticality, business context, and evidence that the response improved the situation.
What The Future MDR Should Prove
The old MDR output was an investigated alert. The future MDR output should be a safer environment. That changes the questions the service should answer:
What percentage of critical assets are covered by EDR, vulnerability scanning, identity telemetry, cloud telemetry, and relevant logs?
Which high-risk exposures were removed this month?
Which attack paths were closed?
Which detections improved because missing telemetry was fixed?
Which response actions were automated safely?
Which risks were accepted by the business?
Which risks were remediated?
Did measurable exposure go down?
This is the reporting layer that matters. Not activity reporting. Not “we reviewed this many alerts.” Not a dashboard that proves the provider was busy.
The stronger MDR report says: here is what exists, here is what is exposed, here is what we saw, here is what we did, here is what changed, and here is the risk that remains.
The Market Implication
The MDR market will split between alert-centric providers and control-plane providers. Alert-centric MDR can still be useful. Many buyers still need 24/7 investigation, escalation, and containment. But that model will be pressured by platform vendors, automation, and buyer expectations for more context.
The more defensible MDR provider will move upstream and downstream at the same time. Upstream, it owns asset context, control coverage, telemetry quality, exposure prioritization, cloud posture, and identity posture. Downstream, it owns containment, remediation orchestration, incident response, validation, and outcome reporting.
That is the future MDR control plane. The category may keep the same name, but the job changes from outsourced alert handling to command central for cyber risk reduction.
I will follow up on this with another MDR post to explore some topics a bit more, such as:
During my engagements with various Private Equity and Venture Capital outlets, I see a clear shift. The questions that is showing up more and more in due diligence is no longer, “What is your AI strategy?”
It is: “How far along are you in rebuilding the company around AI?”
That is a different question.
It applies to startups and incumbents alike. It applies to security companies, SaaS vendors, MSPs, and a lot of businesses outside those markets too. The point is no longer to add a few AI features, automate one workflow, or give employees access to a chatbot. The point is to rethink how the company actually operates.
AI Should Sit Under Every Corporate Function
The companies that will look strongest over the next few years are the ones treating AI as an operating system layer across the business.
That means product development, service delivery, sales and marketing, customer success, and finance and operations are all being reworked with AI in mind. Not as separate experiments, but as connected systems.
The important shift is not “where can we use AI?” It is “how should this function work if AI is built into the process from the start?”
That usually leads to a broader redesign. Workflows get compressed. Handoffs change. Data gets linked across teams. Software that used to just record tasks between humans starts becoming an orchestration layer between people and AI agents.
AI on Top Is Not Enough
Most companies are still treating AI like a feature layer. They add a copilot. They automate a few tasks. They run a few pilots in sales or support. Then they talk as if they have become an AI company. They have not.
If AI is going to matter as much as people claim, then it cannot live in isolated tools and side projects. It has to sit underneath the company as an operating layer. Product, service delivery, sales, marketing, customer success, finance, and operations all need to be rethought with AI built in from the start.
That is the real shift. Not AI as garnish. AI as infrastructure.
In practice, this means a company’s core operating logic can no longer live in forgotten decks, static docs, and tribal memory. Vision, mission, strategic priorities, ICP, and go-to-market motions need to be embedded into the AI layer itself so teams can interact with them in daily work (literally let them chat with these pieces of information via Slack!). The system should be able to explain the strategy, test whether execution matches it, and keep the company aligned as it changes. If that layer does not exist, most companies are still operating on fragments.
This Is Now a Capital Question
This is also why the conversation is changing in private equity and VC diligence.
We are not just looking for AI messaging anymore. We are looking for evidence that the operating model is changing. Is the company shipping faster? Is service delivery getting more leverage? Are teams linked better? Is software being used to orchestrate work between humans and AI agents rather than just record tasks? Is management actually rebuilding the business, or are they still presenting AI as an add-on?
Those questions now matter directly to competitiveness.
A company that keeps the old operating model and bolts AI on top will lose to one that rebuilds around it properly. The latter will move faster, learn faster, and eventually operate at a different level of efficiency.
The Companies That Wait Will Pay For It
I think this is becoming a funding imperative.
Before raising capital, before pursuing a sale, and before the board forces the discussion, management teams need to be doing the hard work of redesigning the company around AI.
Because the market is not going to wait for slow adopters to get comfortable. The companies that embrace AI as a true operating layer will look more scalable, more durable, and more investable. The ones that do not will increasingly look like they are running yesterday’s model in a market that has already moved on.
“AI lowers execution cost, not accountability. SMBs outsource accountability.”
It will affect SMB customers, the MSPs serving them, and the software vendors selling into the channel. Those are three different layers, and the impact on each one is different.
SMBs Still Do Not Want To Own the Problem
One concern is that AI makes knowledge cheaper and tooling easier, so SMBs may decide to manage more of their own IT.
I do not think that is the main outcome.
Most SMBs do not hire an MSP because they cannot access software or information. They hire an MSP because they do not want to own the problem. They want someone else to choose the tools, deploy them, keep them running, support users, stay current, and deal with issues when something breaks.
AI may make parts of IT easier. It does not remove the need for responsibility. That is why I think AI is unlikely to reduce the need for MSPs in any dramatic way.
MSPs Get More Leverage
Inside the MSP, the impact is more direct.
A lot of the work is repetitive: triage, ticket handling, investigation, internal knowledge lookup, and workflow coordination across too many systems. AI can improve all of that.
That does not mean the MSP becomes irrelevant. It means the MSP becomes more efficient.
A smaller team may be able to support more customers, resolve more issues, and operate with fewer manual steps. In security especially, where talent is scarce, that matters a lot. The near-term effect of AI on MSPs is not disintermediation. It is better leverage, better scale, and a different labor model.
MSP Software Vendors Face the Real Reset
The most interesting pressure may land on the MSP software vendors.
The issue is not whether they can add AI features. They all will. The real issue is whether they can get on the AI coding wagon fast enough and turn that into much faster product development.
AI-native development practices will increase the amount of software the market can produce. More gets built. Iteration cycles get shorter. Focused startups can come in faster. And incumbents lose some of the advantage that came from simply being large, embedded platforms.
That is where the moving-fast disadvantage shows up.
Big vendors carry legacy code, older architectures, complex customer requirements, and years of accumulated product sprawl. It is much harder for them to become truly AI-first development organizations than it is for a newer company starting fresh. There is a big difference between developers occasionally using AI and a company rebuilding product, engineering, testing, and delivery around AI-assisted speed.
If incumbents make that shift well, they will benefit enormously. If they do not, AI will not just improve their products. It will make newer competitors much more dangerous.
What Changes From Here
My current view is simple.
AI is probably a tailwind for MSP demand. It is clearly a lever for MSP efficiency. But it may be most disruptive to the software vendors serving the market, because it changes the speed of product development and lowers the barrier for new entrants.
MSPs are not going away. But the basis of competition is changing.
Everyone is suddenly looking at MSP and MSSP rollups. Investors, strategics, even VCs. The logic is obvious. Fragmented market, recurring revenue, sticky customer relationships. But the reality is that only a small subset of providers actually operate at a level worth scaling. The difference between an average MSSP and a good one comes down to a few fundamentals.
Start With Focus
Most MSPs never defined who they serve. They grew organically, took whatever customer showed up, and built a toolkit around individual fires rather than a repeatable model. A strong MSSP starts with clarity. Who is the ICP. What problem is being solved. What the operating model looks like for that segment. When this is missing, everything becomes random. Different tools. Different service quality. No leverage.
In practice, the most important segmentation is not the MSP itself, but who the MSP sells to. An MSP serving restaurants or spas has a fundamentally different security maturity, willingness to pay, and regulatory exposure than one serving regional banks, healthcare, or regulated SMBs. Treating them as one market leads to mispriced risk and churn.
Understand the Economics
Many MSPs think software licensing is their main cost. It is not. Labor dominates the model. At ConnectWise, our Service Leadership dataset showed that roughly 20 percent of MSPs were not profitable because they simply did not understand their own cost structure. The best ones hit around 20 to 25 percent EBITDA. They standardize. They price correctly. They run the business with discipline instead of firefighting.
The real margin killer is not the license costs. It is the technician minutes required to install, manage, respond, document, and bill every tool. Every additional product increases operational drag, even if the license is cheap.
Standardized Security Bundles Win
The MSSPs that scale do not let customers choose their own adventure. They define a required stack. If you want to be a customer, you adopt their bundle. This gives consistency, predictability, and actual security outcomes. A typical bundle includes:
• Patch and vulnerability management • Endpoint protection • Email security • Security awareness • Optional SIEM or MDR depending on the segment
Without standardization, you cannot maintain margins or guarantee service quality. You also make incident response dramatically harder because every environment looks different.
In reality, the bundle is usually sold at a fixed price like $50 to $100 per user per month. Any new security tool must fit inside that number. If it costs $2 to $3 per user, something else must be removed or margin gets cut. This is why getting into the bundle is harder than most vendors expect.
Service Quality Is the Product
SMBs want to be secure. They want minimal disruption. And when something goes wrong, they want a real human who knows what they are doing. Not tier 1 scripts. Not delays during an active incident. Good MSSPs prepare the customer during onboarding. They map critical systems, define escalation paths, understand what can be taken offline, and capture credentials and architecture details. They remove the guesswork from the moment the incident starts.
Billing Needs To Be Simple
One of the fastest ways to lose customers is confusing invoices. Customers want to understand what they pay for. Surprises create distrust. The MSSPs that retain well keep billing predictable, transparent, and boring.
Own the Response, Not Just the Alert
An MDR or MSSP that only notifies customers creates frustration. The provider must take the customer through remediation. For SMBs, response often means restoring operations, identifying the entry point, and closing the gap. If the MSSP cannot do this internally, it must have reliable partners.
How Rollups Actually Create Value
Rollups only work when there is a clear thesis. Some focus on platform unification and a single delivery model. Others focus on professionalizing the business with better hiring, benefits, pricing, and operational rigor. Both paths can work. But they require patience and real operating muscle.
The fastest way to build a defensible platform is often not direct MS(S)P sales but embedding into existing security vendors that already sit in the bundle. Winning a technology alliance with an EDR, MDR, or firewall provider puts you into hundreds of MSPs without forcing each of them to make a new buying decision
Cross border rollups in Europe introduce more complexity. Language and local relationships matter. Regulation varies. Centralizing delivery is possible, but customer interaction often stays local. A standardized platform can still work if the ICP is consistent across regions.
The Microsoft Factor
Many SMBs already own security features through M365. Ignoring this leads to bloated stacks and poor pricing. Smart MSSPs align their offering with what customers already have and fill the real gaps.
The Bottom Line
Building a strong MSSP is not mysterious. It requires a defined ICP, a standardized security bundle, disciplined delivery, true incident readiness, transparent billing, and the ability to take customers all the way to resolution. The providers that do these things consistently are the ones worth scaling. Investors often chase the rollup story, but the real value sits inside the boring operational fundamentals that most of the market never gets right.
Bringing a new product to market is hard—especially for small companies with limited sales resources. While large players can rely on global sales teams, most startups and scale-ups need to be smarter in how they approach their go-to-market (GTM) and route-to-market (RTM) strategies.
Recently, I walked through a set of practical approaches for some of the companies that I work with as an advisor and board member. I wanted to share these lessons more broadly as they might be useful for others as well. These lessons apply broadly to any small technology firm looking to punch above its weight.
Start with Segmentation and ICP Clarity
The first step in any GTM journey is understanding who exactly you are selling to. Segment your market carefully and define your Ideal Customer Profile (ICP). A well-defined ICP keeps you focused and helps you avoid wasting precious time on prospects that aren’t a good fit.
Match the Route-to-Market to Each Segment
Different customer types buy differently. Some may prefer to purchase through a distributor, others via a managed service provider (MSP) or a systems integrator (SI). Aligning your RTM strategy with each ICP segment ensures you meet your buyers where they already are.
Distributors: Give Before You Get
One of the biggest misconceptions startups have is that distributors will automatically champion your product. In reality, distributors expect you to bring them demand first. Show them you can generate business and they’ll start paying attention.
Leverage Technical Partnerships
Forming technical partnerships with larger vendors is often one of the fastest ways to expand reach. These companies already have distribution networks, customer relationships, and market credibility. By integrating or aligning with them, you can ride their coattails into places you couldn’t reach alone.
Ask Your Customers How They Buy
Your existing customers are one of your best sources of intelligence. Ask them:
Do they prefer working with MSPs? Who do you work with yourself?
Do they use certain distributors?
Do they have go-to SIs or VARs?
Not only will you learn more about your market’s buying habits, but customers can often introduce you directly to their providers to short-circuiting months of cold outreach.
Regional VARs: An Untapped Opportunity
Large VARs are tempting, but it’s hard to get their attention. Smaller, regional VARs are usually more receptive, hungry for growth, and open to building mutually beneficial offers. For many startups, these local relationships turn out to be far more productive.
Don’t Rely on Cold Calling Alone
While direct sales will always play some role, scaling purely through cold outreach is rarely sustainable for startups. Partnerships, integrations, and channel leverage amplify your reach, making each sales dollar work harder.
Closing Thoughts
For small companies, success isn’t about brute-forcing your way into the market. It’s about smart leverage. By segmenting effectively, aligning routes-to-market, and building the right partnerships, startups can create multiplier effects that would be impossible through direct selling alone.
The road to market is rarely straight, but with the right GTM strategy, even small players can carve out a strong position in highly competitive industries like cybersecurity.
Thanks to everyone who joined the panel at the BlackHat Innovators & Investors Summit — it was a fast, practical session and full of real, repeatable advice. Below I’ve distilled the conversation into the speakers and the most actionable takeaways founders, investors and channel leaders can use.
Who Spoke
Daniel “DB” Bernard — Chief Business Officer, CrowdStrike
Matt Berry — Global Field CTO, Cyber, World Wide Technology (WWT)
Chris Bisnett — Co-founder & CTO, Huntress
Peter Bryant — Market Analyst, Canalys
Moderator: Raffael Marty, Operating Advisor
Top-line Thesis
Great product is necessary but not sufficient. If you want scale and durability you must design product, GTM, pricing and operations for the channel — MSPs, VARs, MSSPs, distributors and hyperscaler marketplaces. Get those pieces aligned and the channel becomes your growth engine and a moat.
The Most Important, Actionable Insights
1) Start with real customer evidence — then bring partners in
Close a first few deals directly and then ask: Who do you buy through? If the customer uses a reseller or integrator, bring that partner into the next conversation.
A partner introduced by a customer is infinitely more effective than cold outreach.
2) Target, pilot, then scale (regional first)
Don’t boil the ocean. Pick a geography or vertical where a partner has influence, run an enablement-intensive pilot, close a few joint deals, and let the wins spread organically through the partner organization.
Grassroots wins (regional proof points) are how startup products get noticed inside large SIs and disti sales orgs.
3) Engineer the product for MSPs and scale
Some technical must-haves for MSPs: multi-tenancy, frictionless provisioning, usage-based billing, robust reporting, and minimal support overhead (no reboots, simple deployment).
Build integrations with RMM/PSA tools. Partners won’t adopt tools that don’t fit their stack.
4) Use hyperscaler marketplaces as a growth hack
AWS/Azure/Google marketplaces are a procurement shortcut — customers can spend cloud credits and close without long vendor approvals. CrowdStrike and others proved this: marketplace adoption accelerated scale dramatically.
Prioritize marketplace readiness early (billing, security/compliance, packaging).
5) Think of channel margin as external sales / commission
Yes, margins look worse on paper — but compare to the true CAC of building a direct sales force. That margin buys you reach and reduces acquisition risk (you only pay when a partner sells).
Measure partner-sourced vs partner-influenced revenue and the CAC of each.
6) Don’t assume distis/VARs will sell without support
Listing in a distributor catalog is not the finish line. You must: enable, co-market, provide lead flow, run joint sales plays, and sometimes front-end incentives to get sellers focused on your SKU.
Short-term investment in enablement and marketing is how you get long-term pull-through.
7) Build partner economics and enablement as products
Provide free (or low-cost) certification, sales playbooks, demo environments, one-click onboarding, and co-branded assets. These reduce time-to-first-deal and lower partner friction.
Consider usage-based billing to match MSP economics: partners want to align cost with consumed endpoints/services.
8) Decide and double-down on one partner type first
MSP vs MSSP vs VAR vs SI: each requires a different product shape and GTM. Nail one, then expand. Trying to serve all at once dilutes focus and kills momentum.
9) Invest in partner success and low-touch CSM automation
With thousands of SMB endpoints, you can’t scale human CSM for every account. Automate onboarding, monitoring, renewal nudges and migration tools — make it easy for MSPs to manage many customers.
10) Metrics you should be tracking from day 1
Time-to-first-deal with partner (by partner type)
Partner-sourced pipeline and partner-influenced revenue
Onboarding time per MSP customer (time-to-live)
Churn by partner / churn during partner transitions
Net retention for partner-sourced customers
Practical checklist for founders (do this tomorrow)
Pull your top 3 customers and ask: who did you buy through?
Pick one partner (regional or niche) and design a 90-day pilot with joint enablement and a measurable close objective.
Audit product integration: do you have PSA/RMM connectors? If not, roadmap one.
Prepare an AWS/Azure/Google marketplace package (billing, security, description, packaging).
Create a partner enablement kit: demo script, short playbook, 1-page technical install guide, and a free certification.
Model partner economics as commission vs. CAC — present it to your board/investors as external sales.
Instrument partner metrics in your analytics and report them weekly.
Suggested questions to ask a distributor / VAR / SI when exploring partnership
Who in your organization will sell and who will implement our solution? (names/roles)
What does success look like in the first 90 days? How many joint opportunities will you target?
Which 3 vendors do you co-sell with today (and how do we integrate with them)?
What enablement will you need from us (sales motion, demo environment, pricing, rebates)?
How will leads/credit/margin be handled if a customer comes direct?
For investors: what to look for in a channel-first startup
Product designed for the channel: multi-tenancy, RMM/PSA integrations, usage billing.
Early partner proofs: paying partners or partner-introduced deals, not just distributor listings.
A go-to-market playbook for partner enablement (documented processes, enablement kits, measurable time-to-first-deal).
Marketplace strategy and early traction (even if small, momentum matters).
Closing takeaways (what I heard loud and clear)
The channel is not a shortcut — it’s a discipline. If you commit, build for it, and invest in the partner motion, channel-first companies scale faster and with lower long-term CAC.
Start with customers, pilot locally with partners, engineer for MSP realities, and use marketplaces to accelerate procurement.
Win through repeatable partner plays and measurable enablement — wins scale inside partner organizations.
Thanks again to BlackHat for having us and to the panelists to take time out of their busy schedules to impart these very actionable insights.
