NinjaOne RMM Integration

The NinjaOne integration is Regentra’s RMM-class device-source. One MSP credential per NinjaOne regional tenant feeds two outputs simultaneously:

• PSA asset sync — every NinjaOne customer organization you map to a PortalCompany contributes its approved devices to that company’s Asset list in the PSA module. Updated every 4 hours.
• Compliance evidence sweep — for each mapped customer that has been promoted to a Regentra compliance tenant, five aggregate-only signals refresh every 6 hours: disk encryption posture, antivirus posture, patch SLA, backup activity, and device inventory. Each signal maps to multiple Internal Controls in the CCF catalog.

NinjaOne customers who are NOT compliance-promoted still flow into PSA assets; they just don’t generate evidence signals. This lets an MSP sell compliance to a subset of their book without contaminating the compliance-enabled customers’ evidence with other customers’ device counts.

​

What you give Regentra

A single OAuth scope is required: monitoring (read-only). Regentra deliberately does not request management (write access) or control (remote-control sessions) — both are out of scope for compliance evidence collection.

​

Required permissions in NinjaOne

When you create the API Client: System Administrator role is required to create the API client itself. The client, once created, has no role of its own — it sees whatever the monitoring scope grants on that tenant.

​

Setup

The full step-by-step lives inline on the NinjaOne card in Settings → Integrations. The short version:

​

Mapping NinjaOne organizations to PSA companies

NinjaOne organizes its customer device fleets under “organizations” inside your tenant. Each NinjaOne organization binds to exactly one Regentra PortalCompany — or is explicitly marked “don’t sync” so it stays out of both PSA and compliance. After your first save, click Review organization mappings → on the integration card. Regentra walks NinjaOne’s /organizations endpoint and surfaces every customer org with:

• The current mapping state (Pending review / Mapped / Ignored)
• A suggested PortalCompany if Regentra can match by exact name (case-insensitive)
• Action buttons: Use existing, Create new, Don’t sync

For each row:

• Use existing binds the NinjaOne org to a PortalCompany you already have in PSA.
• Create new creates a fresh PortalCompany using the NinjaOne org’s name. If a PortalCompany with that name already exists, Regentra reuses it instead of duplicating.
• Don’t sync records the mapping as IGNORED so re-discovery doesn’t keep prompting you. Devices from that NinjaOne org never flow into Regentra.

The mapping survives credential reconnect — disconnecting and reconnecting NinjaOne doesn’t force you to re-map every customer.

​

PSA asset sync

Devices are filtered to approved before pulling — pending and rejected devices stay in NinjaOne but are skipped by sync. If the sync hits NinjaOne’s 10,000-device-per-org ceiling, the audit log records truncatedAny: true so you can see the shortfall without checking each customer manually.

​

Per-company sync

The PSA Company detail page (when bound to a NinjaOne org) exposes a Sync With NinjaOne button next to the existing Sync With M365 button. It queues an Inngest event scoped to one mapping so a single customer can be refreshed on demand without waiting for the next 4-hour cron tick.

​

Compliance evidence sweep

For every NinjaOne organization mapped to a PortalCompany that has been promoted to a Regentra compliance tenant, the evidence sweep collects five aggregate-only signals every 6 hours. The five signals:

​

What lands in MonitoringSignal.metadata

Aggregates only. Every signal metadata object carries counts, percentages, vendor distributions, and bucket counts — never hostnames, IPs, serial numbers, drive letters, or last-logged-on-user values. The Trust Center reads from the same table; per-device identifiers in metadata would leak customer device inventory if the customer’s Trust Center is public. This is enforced by an automated test that scans every aggregator’s output against a PII deny list.

​

Tenant isolation

The evidence sweep is a two-stage Inngest pipeline:

1. A scheduled cron runs on the MSP scope, lists active NinjaOne credentials, joins to mappings whose PortalCompany has been compliance-promoted, and emits one event per (mspCredentialOrgId, customerComplianceOrgId, mappingId, region, externalOrgId) tuple.
2. A per-customer worker reads the event, decrypts the MSP credential, pulls the customer’s data from NinjaOne, and writes signals into the customer’s compliance tenant — not the MSP’s. Concurrency is keyed on the customer’s compliance org so two customers’ sweeps run in parallel.

The worker’s source carries automated tests that assert:

• Every credential lookup uses the MSP’s organization id.
• Every collectEvidence call’s destination is the customer’s compliance organization id.
• Every audit log row lands on the customer’s compliance organization.
• Variable naming never conflates the two ids.

​

First-sync dry-run

The first compliance sweep after you connect NinjaOne writes signals but suppresses the auto-ticket bridge — the operator-visible flag firstEvidenceSyncedAt is NULL until the first successful sweep. This means: a 50-customer MSP turning NinjaOne on doesn’t wake up to 250 HIGH-priority tickets on day one if every customer happens to have failing antivirus or outstanding patches. After the first sweep completes, the flag is stamped and subsequent sweeps route findings to the MSP’s PSA queue through the standard bridge.

​

Internal Control mappings

Each Internal Control crosswalks to its framework requirements in the CCF (HIPAA, SOC 2, NIST CSF, ISO 27001, CMMC, PCI DSS, GDPR, FTC Safeguards). One NinjaOne signal evidences the same control across every adopted framework simultaneously.

​

Disconnecting NinjaOne

Disconnect from the integration card. Regentra:

1. Zeros all encrypted credential columns and flips isActive=false.
2. Retires every Asset row with externalSource = "ninjaone" in the MSP org (rows preserved for historical traceability; status="RETIRED" takes them out of the active list).
3. Writes an audit log row on every customer compliance tenant that the disconnect affects, so each customer’s auditor sees the NINJAONE_DISCONNECTED event in their trail.
4. Leaves existing MonitoringSignal rows alone — they age out naturally via their 7-day expiresAt. The auditor needs to see “the integration was disconnected with N signals already collected” at the moment of disconnect; wiping them would erase that record.
5. Leaves IntegrationOrgMapping rows alone, so a future reconnect doesn’t force you to re-map every customer.

If you reconnect the credential (same region) using new credentials at NinjaOne’s side, the mapping table is preserved and the next cron run resumes evidence collection on every previously mapped customer.

​

Rate limits and pagination

NinjaOne enforces per-tenant rate limits (1500 requests/hour sustained, 200/min burst). Regentra’s sync workers stay comfortably under that cap on every cadence we ship:

• 4-hour PSA sync: one /organizations list + one /devices-detailed page per mapped customer.
• 6-hour compliance sweep: six endpoints per customer.

Both syncs honor X-RateLimit-Remaining and log a warning if it drops below 100. Discovery requests cap at 5,000 organizations and 10,000 devices per organization; if you exceed either, the sync records a truncated: true marker in metadata so you can see the shortfall in the audit log.

​

Troubleshooting

​

What this integration does NOT do

• No remote control sessions. Regentra never requests the control scope, even if NinjaOne offers it.
• No write-back to NinjaOne. Regentra never requests the management scope. Future read-write features (e.g., setting a regentra_compliance custom field per device) would require an explicit opt-in toggle in the integration card.
• No per-event device telemetry. The activity log is sampled only as aggregates for the backup-activity signal; individual device events are not persisted in Regentra.
• No NinjaOne webhook ingestion (yet). When webhooks ship in a later phase, they’ll mirror the Stripe / Level webhook security posture (HMAC-signed payloads, replay window, idempotency).