A typical morning for a security-conscious MSP looks like four browser tabs and a coffee. NinjaOne for endpoint alerts. Huntress for EDR and ITDR incidents. Cork for compliance posture and vulnerabilities. And whatever firewall or email-security console rounds out the stack. Every tab has its own severity language, its own "what's new since yesterday," and its own idea of how urgent urgent is.

The problem isn't that any one of those tools is bad. They're all good at the thing they do. The problem is that the human in the chair has to be the integration layer — mentally merging four severity scales and four notification streams into a single answer to one question: what actually needs a person today?

When we built the Security module in Morton Command Center, that question was the whole design brief. Not "replace your security tools" — they stay exactly where they are. The goal was to pull their alerts into one normalized, severity-ranked triage queue so the bouncing-between-tabs tax disappears. Here's how that actually works, and — just as important — where the honest limits are.

Three vendors, three completely different alert shapes

The first thing you learn building this is that "an alert" means something different to every vendor, so you can't just dump them into one list and sort by a field that doesn't exist.

We name NinjaOne, Huntress, and Cork as examples — but the platform is API-driven, so the category is what matters, not the logo. If your tool has an API, we build the integration for it — custom to your stack. Run SentinelOne or CrowdStrike instead of Huntress, Datto or ConnectWise RMM instead of NinjaOne, a different compliance scanner instead of Cork? Any of them with an API connects the same way — every integration is built custom to your stack as part of your engagement.

To make those comparable, every vendor gets its own normalizer that maps the source's native fields onto one shared model: a single Critical / High / Medium / Low severity scale, a company, a vendor tag, a timestamp, and a status. Cork High doesn't automatically equal NinjaOne High — part of building each normalizer is deciding, deliberately, how that vendor's scale lines up with the unified one. Once an alert is in the shared shape, the queue can rank a Huntress incident, a Cork vulnerability, and a Ninja device condition against each other in one ordered list, top of the page being "deal with this first."

Because the mapping lives in the normalizer and not in the UI, adding a vendor is additive — as long as the tool exposes an API, we build its normalizer and its findings flow into the same queue everyone already knows how to read. That's the whole reason the queue isn't locked to three logos: whatever your security stack is, the category — RMM, EDR, compliance, firewall, email security — is what the model is built around, not the specific brand. This is the advantage over a rigid all-in-one suite that forces you onto its pre-built integration list — your queue is built to fit your exact stack and workflows, not the other way around. We do the same for the firewall and email-security side of the house, which on the security page join the unified model alongside the three above.

The part everyone gets wrong: what you can act on

This is the section we're most careful about, because it's where security tooling marketing tends to overpromise, and where an MSP can get badly burned by a tool that says it remediates and doesn't.

Here's the honest line: Morton Command Center does not isolate hosts, quarantine files, block traffic, or auto-remediate threats on its own. That's the security vendor's job, and we are deliberate about not pretending otherwise. What CC does is surface and triage everywhere, and write back only where the vendor's API genuinely lets us.

In practice that breaks down cleanly:

The same read-only honesty applies to the rest of the stack: your pen-test tool (vPenTest, for example), your firewall (SonicWall, or any firewall with an API, gets an integration the same way), and your email-security platform (Check Point, for example) all flow into the queue as visibility, and any "remediation status" you track on a finding is stored locally in CC, not pushed back to the vendor. The mental model is simple: visibility and triage on everything, write-back to the vendor only where the vendor's API allows it — full read-write with Huntress, and the same for any EDR whose API supports those actions.

Near-real-time, and why that's the right promise

You'll notice we don't say "real-time." The queue is warmed by scheduled background syncs — Huntress incidents about every two minutes, Cork on a multi-hour cycle, NinjaOne and the rest on their own cadences — plus a manual Refresh when you want to force the issue. So a brand-new Huntress incident lands in the queue within minutes, not the instant it fires.

That's a deliberate trade, and it's the right one for triage. A queue you check a few times a day doesn't need millisecond freshness; it needs to be complete and correctly ranked when you look at it. Cron-warmed caches also mean the page loads fast and you're not hammering five vendor APIs on every refresh — and the warming is gated on real human presence, so we're not burning vendor rate limits syncing for a dashboard nobody's watching at 3 a.m.

Per-client scoping, because not every tech sees everything

One thing the four-tabs workflow handles badly is scope. If you've got a technician assigned to a subset of clients, you don't want them triaging — or even seeing — security alerts for companies that aren't theirs. CC's role-based access control scopes the security queue server-side: a scoped agent sees alerts only for their assigned companies, enforced in the API, not just hidden in the UI. Every company also has its own Security tab on its detail page, so you can drop from the org-wide queue into one client's full posture without losing the thread.

What this actually changes about the morning routine

The before-and-after is mundane in the best way. Instead of opening four consoles and reconciling four severity scales in your head, you open one queue that's already sorted by what needs a human today. Huntress incidents you can approve or resolve right there. Cork and NinjaOne items you can read, triage, and route — Cork cleared locally, Ninja device issues one hop from the controls that fix them. The firewall and pen-test noise is visible without being a fifth tab.

It doesn't make your MSP more secure by magic — your security tools do that. What it does is make sure nothing falls through the cracks between tools, which is where most missed alerts actually live. The gap between "Huntress flagged it" and "a human looked at it" is exactly the gap a unified queue closes.

If you want the full picture of how the security layer is built — every vendor, every severity mapping, what's read-only and what's not — we go deeper on the unified NinjaOne, Huntress, and Cork page and the broader MSP security operations overview. And if you're curious how the same normalize-then-unify approach plays out on the ticketing side, the Freshdesk + NinjaOne workflow post walks through it for device data and tickets.

The honest bottom line

Unifying security alerts isn't a remediation engine and we won't sell it as one. It's a visibility-and-triage layer that respects what each vendor's API actually allows: full read-write where Huntress permits it, read-and-route everywhere else, and a clear local resolve where the vendor itself is read-only. That honesty is the point. A queue that tells you the truth about what it can and can't do is worth far more than one that quietly leaves your compliance state out of sync with the tool of record.

Pricing, if you're wondering, is flat-rate — no per-seat, per-client, or per-alert fees. See current pricing on the homepage →