Skip to content

TotlProvision — Deep Roadmap & Industry Gap Analysis

This is the "go deep" companion to Build plan & roadmap. BUILD-PLAN stays the concise, decision-locked overview; this document is the detailed engineering + product plan: what we've built (Phases 0–6), what the market leaders do, where our gaps are, and exactly what to build to make TotlProvision the best Windows deployment + fleet-management product an MSP can sell.

Scope decision: Windows-only, as deep as possible. Bets: security & compliance, scale & reliability, MSP commercial product, and deployment breadth/UX — all four. Benchmarked against named competitors. Drafted 2026-07-14.

1. Positioning: what "best in the world" means here

The Windows endpoint market in 2026 is fragmented across four tool categories, and no single tool owns the MSP-white-label seam:

Category Leaders What they nail What they miss for MSPs
Cloud OS provisioning Microsoft Autopilot / Autopilot Device Preparation (v2) Zero-touch OOBE, dynamic enrollment, OEM-optimized transform-in-place Entra/Intune-only, no white-label, weak for on-prem/hybrid, no per-MSP resale
Modern imaging OSDCloud (Recast), WAPT Bare-metal WinPE, dynamic DriverPacks, driver management Not a management plane, no reporting/escrow, no product layer
RMM / patch / desired-state NinjaOne, Action1, Immy.bot, PDQ Connect Patching, P2P distribution, desired-state, multi-tenant, drift remediation Provisioning is shallow; escrow/imaging weak; pricey module stacking
Config hardening Intune Security Baselines, CIS-CAT, PowerSTIG, WinUtil CIS/STIG baselines, attestation, compliance evidence Not integrated with provisioning, no zero-knowledge secret handling

MDT — the tool a generation of MSPs used for imaging — was officially retired by Microsoft on January 6, 2026 (no more updates, fixes, or support), and its natural successor OSDCloud is a PowerShell imaging framework, not a management plane. That leaves a real, timely opening.

The TotlProvision thesis: be the one product that spans bare-metal → provisioned → hardened → enrolled → continuously managed → migrated, is white-labelable and resellable by MSPs to other MSPs, and is secure-by-default with zero-knowledge secret escrow — a combination that Autopilot (cloud-locked), OSDCloud (imaging-only), and the RMMs (provisioning-shallow) each only partially cover. We already have the hard, differentiated parts (zero-knowledge escrow, tenant-aware backend, transform-in-place engine). The work below turns that into a category-defining product.

The 10 pillars of a best-in-world Windows deployment product

  1. Bare-metal to business-ready — image or transform-in-place, either path.
  2. Driver & firmware currency — vendor-native, dynamic, verifiable.
  3. Secure-by-default — CIS/Microsoft baseline as code, LAPS-style rotation, BitLocker + escrow.
  4. Zero-knowledge secret custody — the escrow nobody else has; break-glass that actually works.
  5. Desired-state + drift remediation — provisioning is step one; staying provisioned is the product.
  6. Fleet operations at scale — 10k+ machines, rings/cohorts, P2P distribution, resilient reporting.
  7. Attestation & compliance evidence — prove the baseline held; export auditor-ready reports.
  8. Multi-tenant, white-label, sellable — RBAC, branding, licensing, billing, tenant self-service.
  9. Observability & audit — tamper-evident trail, live progress, actionable failure surfacing.
  10. Safety & reversibility — dry-run, rollback/undo, VM test harness, signed & versioned packages.

We fully or partially cover pillars 3, 4, 9, and the provisioning half of 1. Pillars 2, 5, 6, 7, 8, 10 are where the deep roadmap concentrates.

2. Where we are today (Phases 0–6)

A concise inventory so the gap analysis has a baseline. Engine modules today: Totl.Core, Crypto, Security, Report, Enroll, Summary, Inventory, Offline, Preflight, Validate, Bios, Rename, Power, Locale, Domain, Dell, Edition, Autopilot, Bitlocker, Debloat, Office, Apps, Rmm, Updates, Migrate. Backend: Cloudflare Worker + D1 (tenant-aware). Portal: Cloudflare Pages behind Access/Entra SSO with zero-knowledge reveal and an admin console.

  • Phase 0 — Foundations. Tenant-aware D1 schema; Worker API; zero-knowledge RSA-OAEP + AES-GCM escrow (private key never touches Cloudflare); portal; CI; docs site.
  • Phase 1 — Build system. Build-Release.ps1 stages a runtime-only tree and compiles two Inno artifacts (authoring installer + per-machine provision exe), optional Authenticode signing.
  • Phase 2 — Security hardening. Totl.Security: LSA-backed autologon (no plaintext DefaultPassword), crash-proof credential-cleanup watchdog, env/prompt secret resolution, SHA256-pinned downloads, release signing.
  • Phase 3 — Reporting & escrow. Totl.Report/Totl.Enroll post run results + escrow secrets; portal dashboard, secret reveal, audit; admin CRUD (tenants/users/API tokens/machines).
  • Phase 4 — Deployment parity. BitLocker enable + recovery-key escrow; Dell Command Update; on-prem domain join; edition upgrade; locale/timezone/keyboard/Wi-Fi; Autopilot hardware-hash harvest; richer asset inventory; offline cached-installer mode.
  • Phase 5 — Native migration. Totl.Migrate: native sidReassign (ProfileList/icacls/hive) + copyData (robocopy + OneDrive KFM), dry-run + VM-gated; Profwiz/USMT kept as documented fallback.
  • Phase 6 — UX/operability. Preflight gate; post-provision validation; native WinUtil "Standard" tweak parity (no runtime christitus.com dependency); GUI presets/load/search; live progress + end-of-run PASS/FAIL summary.

Engineering pattern worth preserving everywhere below: each phase splits a pure, unit-tested decision/plan function from side-effecting apply code. That is our reliability moat and must extend to every new capability.

3. Deep dives: Phases 1–6 vs. the industry

Each section: What we have → What leaders do → Gaps → Deep plan.

3.1 Build system & artifacts (Phase 1)

What we have. Runtime-only staging + two Inno EXEs; optional signing; a manifest test that proves no secrets leak into dist/.

What leaders do. Autopilot v2 avoids artifacts entirely (cloud transform-in-place). OSDCloud ships a versioned PowerShell module + WinPE boot media with dynamic content pulled at runtime. Modern distribution expects signed, versioned, reproducible builds and an update channel (stable/beta).

Gaps. (a) No release channel / auto-update of the on-box engine; (b) builds aren't reproducible or SBOM'd; (c) single packaging path (Inno) — no MSI/MSIX for enterprise deployment; (d) no delta updates.

Deep plan. - Signed update channel. Publish engine releases to R2 with a signed manifest.json (version, SHA256, min-compat). On-box Totl.Update checks the channel (stable/beta), verifies signature + hash, and self-updates — the same pinned-download discipline we already have, applied to ourselves. - Reproducible builds + SBOM. Deterministic staging, embed a generated SBOM (module list + hashes + versions) into the release and into the run report for supply-chain attestation. - MSI/MSIX authoring installer alongside Inno for shops that deploy the authoring tool via Intune/GPO. - Cosign/sigstore-style transparency (stretch): publish release hashes to an append-only log so tenants can verify what shipped.

3.2 Security hardening (Phase 2) + the missing baseline engine

What we have. LSA autologon, credential-cleanup watchdog, pinned downloads, signing, per-machine password rotation (via enrollment), BitLocker + escrow.

What leaders do. This is the biggest single gap. The industry standard is a security baseline as code: CIS Benchmarks are the auditor-recognized policy target; Microsoft Security Baselines are the practical MDM/CSP implementation vehicle; STIG (SCAP/PowerSTIG) for DoD-grade. Tools like CIS-CAT validate and score against the benchmark and produce prioritized remediation. LAPS is considered "indispensable" to any hardening baseline. BitLocker recovery escrow to Entra is table stakes.

Gaps. We harden some settings (WinUtil "Standard" tweaks) but have no formal baseline, no scoring/attestation, no CIS/STIG mapping, no LAPS-grade lifecycle (we rotate at enrollment but don't manage rotation cadence/history/read-audit like LAPS), and no ASR/Defender/Firewall policy engine.

Deep plan — this is arguably the highest-value new capability. - Totl.Baseline — baseline-as-code engine. A declarative baseline document (JSON/PS data) mapping controls → registry/CSP/secedit/auditpol actions, each tagged with its CIS control ID and Microsoft-baseline reference. Ship curated baselines: Totl-Standard, CIS-Level-1, CIS-Level-2, STIG. Reuse the pure-plan pattern: Get-TotlBaselinePlan (pure, testable) → apply. - Scoring + attestation. Test-TotlBaseline scans current state vs. the baseline and emits a compliance score + per-control pass/fail with evidence (like CIS-CAT). Push the attestation to the backend so the portal shows a fleet compliance heatmap and can export an auditor CSV/PDF. - LAPS-grade admin credential lifecycle. Rotation cadence, history, and read-auditing of the local-admin password (every reveal already audits; add scheduled rotation + expiry + "rotate on reveal"). Optionally interoperate with Windows LAPS. - Defender/ASR/Firewall/Exploit-Guard policy module with the same baseline mapping. - Drift-aware: baseline compliance feeds the desired-state engine (3.7 / §4.2) so a machine that drifts out of CIS-L1 is auto-remediated on the next maintenance session.

3.3 Reporting & escrow (Phase 3)

What we have. Run reporting, zero-knowledge secret escrow + reveal, audit, admin CRUD, per-tenant API tokens. This is genuinely ahead of the field on secret custody — Autopilot/Intune escrow BitLocker to Entra but hold the keys; we physically can't read escrowed secrets.

What leaders do. RMMs provide live dashboards, alerting, webhooks, and SIEM export. Compliance tooling provides evidence packs. Everyone integrates with PSA/ticketing (ConnectWise, Halo, Autotask).

Gaps. (a) Break-glass / key recovery is designed but not implemented — a lost tenant private key = unrecoverable secrets (Shamir M-of-N is specified in BUILD-PLAN, not built); (b) no alerting / webhooks / PSA integration; (c) audit log is append-only by intent but not tamper-evident (no hash chaining); (d) no secret rotation history or expiry surfaced in the portal.

Deep plan. - Ship the break-glass design. Shamir Secret Sharing of the tenant private key (M-of-N shares to named custodians), sealed offline recovery kit generation, and a documented, audited recovery ceremony. Nothing else matters if a tenant can lose all their secrets. - Tamper-evident audit. Hash-chain audit rows (each row includes the prior row's hash); periodic anchoring so tampering is detectable. Export signed evidence bundles. - Integrations. Outbound webhooks on run/secret/compliance events; a PSA connector (ConnectWise Manage / Halo) to open tickets on failures; optional SIEM (JSON/CEF) export. - Secret lifecycle in the portal. Show rotation history, expiry, last-reveal, and per-secret break-glass status.

3.4 Deployment breadth (Phase 4) + imaging & patching

What we have. BitLocker+escrow, Dell drivers, domain join, edition upgrade, locale/Wi-Fi, Autopilot hash harvest, richer inventory, offline mode. Our transform-in-place philosophy matches Autopilot v2's OEM-optimized approach (turn the preinstalled OS business-ready, don't reimage).

What leaders do. - Imaging: With MDT retired, OSDCloud owns bare-metal WinPE deploys with dynamic DriverPacks downloaded in WinPE. Autopilot v2 avoids imaging by transforming in place. - Drivers beyond Dell: OSDCloud DriverPacks + vendor tools (Lenovo Vantage/Commercial, HP Image Assistant) cover the fleet; we only do Dell. - App deployment: winget (built-in), Chocolatey, and Patch My PC (curated third-party catalog, the de-facto standard for keeping 3rd-party apps current) — with P2P distribution (Action1) to avoid re-downloading per endpoint at scale. - Patch management as an ongoing discipline (not just "run Windows Update once"): rings, deadlines, reboot orchestration, third-party patching, vulnerability-driven prioritization.

Gaps. (a) No bare-metal imaging path — we only transform an existing OS; (b) Dell-only driver management; (c) app install is winget/choco/URL but no curated third-party patch catalog and no ongoing patch lifecycle; (d) no P2P/peer caching at scale; (e) no Autopilot profile assignment, only hash harvest.

Deep plan. - Totl.Image — OSDCloud-class bare-metal path (optional). WinPE boot media (our Build system already makes media) → apply a serviced image → dynamic driver packs → hand off to the existing provisioning engine. Positions us as the MDT successor and the management plane OSDCloud isn't. - Multi-vendor drivers. Generalize Totl.Dell → Totl.Drivers with Lenovo (Commercial/Vantage) and HP (Image Assistant) providers behind one config, plus an OSDCloud-DriverPack fallback. - Totl.Patch — patch lifecycle + third-party catalog. A curated, signed app/patch catalog (Patch My PC-style) hosted in R2; ring/deadline scheduling; reboot orchestration; and peer/P2P caching (one download per site, shared LAN-side) for 10k-scale bandwidth. Vulnerability-driven prioritization by consuming CVE feeds. - Autopilot end-to-end. Beyond hash harvest, optionally register the hash to Intune via Graph and assign a profile (for MSP clients who are Intune shops) — meeting them where they are.

3.5 Native migration (Phase 5)

What we have. Native sidReassign + copyData, dry-run + VM-gated, Profwiz/USMT fallback. This is already differentiated — most RMMs don't do profile migration at all.

What leaders do. ForensiT Profwiz (paid) and USMT are the references; SID reassignment for local→local, on-prem, and Entra is the hard part. Enterprise migration tools add scheduling, rollback, and verification.

Gaps. (a) Live apply of sidReassign is intentionally withheld pending the VM test harness (§4.10) — that harness is the unlock; (b) no verification/rollback of a migration; (c) Entra→Entra and cross-tenant still lean on Profwiz.

Deep plan. - Build the VM test harness first (§4.10), then lift the sidReassign apply gate behind proven, automated VM validation runs with before/after assertions. - Migration verification + rollback. Pre-migration ProfileList/ACL snapshot; post-migration assertions (profile loads, ACLs correct, data present); one-command rollback from the snapshot. - Native Entra reassignment research (dsregcmd + AAD SID mapping) to eventually retire the paid Profwiz dependency entirely.

3.6 UX / operability (Phase 6)

What we have. Preflight gate, post-provision validation, native tweak parity, GUI presets/load/ search, live progress + PASS/FAIL summary. Solid for a technician building a config.

What leaders do. Immy.bot and the RMMs offer web-based, multi-tenant dashboards with live maintenance-session progress, per-tenant overrides, and self-service. Autopilot shows enrollment status pages. The bar is a fleet view, not a per-machine GUI.

Gaps. (a) Config authoring is a local WPF GUI; the portal can't yet author/assign configs; (b) no live fleet view of in-flight provisioning; (c) no self-service (end-user or client-admin); (d) validation is per-run, not a continuous fleet compliance view.

Deep plan. - Move config authoring into the portal. Server-side config store (versioned), a web config editor (the WPF form's fields, but multi-tenant and assignable to cohorts), and per-tenant overrides (Immy.bot's "most specific wins" model). Keep the WPF GUI as an offline fallback. - Live fleet + session view. Stream phase progress to the backend (we already emit per-phase progress) → portal shows in-flight machines, current phase, and PASS/FAIL as they finish. - Self-service portal (Phase 7 overlap): client-admins see their own fleet, reveal their own secrets (RBAC-scoped), and trigger approved actions.

4. New capabilities (deep) — the path to best-in-world

These are net-new pillars, ordered by leverage. Each keeps the pure-plan/tested pattern.

4.1 Security baseline & compliance engine (Totl.Baseline)

See §3.2. Highest-value addition. CIS/Microsoft/STIG baseline-as-code + scoring + attestation + LAPS-grade credential lifecycle + Defender/ASR/Firewall policy. Turns "we set some tweaks" into "auditor-recognized, continuously-proven compliance." Feeds §4.2.

4.2 Desired-state & drift remediation engine (Totl.State)

The Immy.bot differentiator, and the thing that converts a one-time provisioning tool into a recurring, sticky, resellable product. Model: declarative desired state + scheduled maintenance sessions that detect current state, build a plan, apply only deltas (idempotent), verify, and report — exactly Immy.bot's loop. Cross-tenant deployments with tenant/cohort overrides, "most specific wins." Every existing phase becomes a desired-state provider (baseline drift, missing apps, telemetry re-enabled, BitLocker turned off → auto-remediate). This is where recurring MSP revenue lives.

4.3 Fleet operations at scale (10k+)

  • Rings/cohorts (pilot → broad → all) with deadlines and pause/rollback.
  • P2P / peer caching for installers and patches (Action1's bandwidth model) — one download per site.
  • Resilient reporting — we have offline store-and-forward; add backoff, dedupe, and a fleet health SLO dashboard.
  • Scale-test the backend — D1 read/write patterns, R2 for bulk logs, rate limits, and cohort queries.

4.4 Patch & third-party app catalog (Totl.Patch)

See §3.4. Curated signed catalog in R2, ring/deadline scheduling, reboot orchestration, CVE-driven prioritization, P2P distribution.

4.5 Bare-metal imaging (Totl.Image)

See §3.4. OSDCloud-class WinPE path as the MDT successor; optional, complements transform-in-place.

4.6 Multi-vendor drivers & firmware (Totl.Drivers)

See §3.4. Dell + Lenovo + HP providers + DriverPack fallback; firmware/BIOS currency with verification.

4.7 MSP commercial layer (Phase 7, deepened)

  • RBAC — provider-admin vs. tenant-admin vs. engineer vs. read-only; who edits configs vs. reveals secrets vs. runs actions. (We have admin/engineer; deepen to a real policy model.)
  • White-label branding — per-tenant logo/colors/name across installer, GUI, portal, and reports.
  • Licensing / activation / metering — per-seat entitlement, usage metering, and billing export (the market runs $1.50–$3.75/endpoint/mo; we should meter cleanly and let MSPs mark up).
  • Tenant self-service — client-admins manage their own fleet within RBAC scope.
  • Package library — versioned, integrity-signed app/config/baseline library with an approval flow.

4.8 Observability & audit

Tamper-evident hash-chained audit (§3.3), structured logs to R2, live fleet/session view (§3.6), webhooks + PSA/SIEM integration, and per-tenant SLA/health reporting.

4.9 Rollback / undo & config versioning

Every tweak/baseline/app action records an inverse where feasible; config and baseline documents are versioned with diff + rollback; migration snapshots (§3.5). "Reversibility" is pillar 10 and a trust differentiator vs. fire-and-forget scripts.

4.10 VM test harness & provisioning CI

Automated, disposable VM runs of a full provisioning + migration cycle with before/after assertions, gating live sidReassign and any destructive apply. This is also what lets us ship faster safely — it's the unlock for §3.5 and de-risks §4.1/§4.2. Build on Hyper-V/cloud VMs invoked from CI.

4.11 Key recovery / break-glass (Shamir)

See §3.3. Non-negotiable before scaling escrow: Shamir M-of-N of the tenant private key, sealed offline kits, audited recovery ceremony.

5. Architecture deepening

  • Agent model. Today the engine is invoked at provisioning + enrollment. Desired-state (§4.2) needs a lightweight recurring agent (scheduled task or service) that runs maintenance sessions, checks in, and pulls assigned state — without becoming a heavyweight RMM. Keep it thin; interoperate with existing RMMs (Immy.bot's model) rather than replace them.
  • Control-plane security. Worker + D1 + R2, Access/Entra SSO, per-tenant API tokens (hashed). Add mTLS or signed-request auth for the agent channel; rotate tokens; scope tokens per capability.
  • Data model growth. Add tables/objects for: baselines & compliance results, desired-state assignments, patch catalog + rings, license/metering, package library versions, webhooks. Keep tenant_id on everything; R2 for bulk logs/evidence.
  • Zero-knowledge everywhere. Any new retrievable secret class (Wi-Fi PSK, domain creds, edition key, BIOS password) flows through the same RSA-OAEP + AES-GCM envelope; the backend stays unable to read plaintext. Break-glass (§4.11) is the safety net.
  • Reproducibility & supply chain. Signed engine releases, SBOM in the report, pinned downloads, AllSigned posture — extend to the catalog and agent.

6. Prioritized roadmap (sequenced, with rationale)

Ordering optimizes for trust → stickiness → scale → commercial, because a deployment product that can lose secrets or drift silently can't be sold at scale.

  1. P7a — Break-glass (Shamir) + tamper-evident audit (§4.11, §3.3). Trust floor. Unlocks selling escrow.
  2. P8 — Security baseline & compliance engine (Totl.Baseline, §4.1). Biggest differentiated value; auditor-recognized.
  3. P9 — VM test harness & provisioning CI (§4.10). De-risks everything after; unlocks live migration.
  4. P10 — Desired-state & drift remediation (Totl.State, §4.2). Converts to recurring revenue; the Immy.bot moat.
  5. P11 — Fleet ops at scale + live fleet view (§4.3, §3.6). 10k-ready; portal becomes a fleet console.
  6. P12 — Patch lifecycle + third-party catalog + P2P (Totl.Patch, §4.4). Ongoing management parity with RMMs.
  7. P13 — Multi-vendor drivers + firmware (Totl.Drivers, §4.6). Fleet-wide driver currency, not Dell-only.
  8. P14 — MSP commercial layer (RBAC, white-label, licensing/metering, self-service, package library, §4.7). Make it sellable/resellable.
  9. P15 — Bare-metal imaging (Totl.Image, §4.5). MDT successor; optional but category-defining.
  10. P16 — Rollback/undo + config versioning + portal config authoring (§4.9, §3.6). Reversibility + web authoring.
  11. P17 — Integrations (webhooks, PSA, SIEM, Autopilot end-to-end, §3.3/§3.4). Fit into MSP stacks.
  12. Cross-cutting — signed update channel + SBOM + best-practice script review (§3.1 + the BUILD-PLAN smell list).

Rationale: P7a/P8/P9 are the trust and safety base; P10/P11/P12 are the stickiness and scale that justify recurring pricing; P14 is commercialization; P15/P16/P17 broaden and polish. Every item keeps the pure-plan + Pester/CI discipline and the zero-knowledge invariant.

7. Success metrics (how we'll know it's best-in-world)

  • Provisioning: time-to-business-ready; unattended success rate; reboots per run.
  • Security: % fleet at CIS-L1/L2; mean time to remediate drift; escrow coverage; break-glass tested.
  • Scale: machines/site per download (P2P efficiency); report delivery SLO; 10k-tenant query latency.
  • Reliability: phase failure rate; rollback success; VM-harness pass rate before release.
  • Commercial: tenants onboarded self-service; white-label deployments; metered-billing accuracy.

8. Non-goals (deliberate focus)

Cross-platform (macOS/Linux/mobile) is out of scope for this plan — Windows depth first. We do not aim to replace full RMMs (remote control, ticketing, monitoring); we integrate with them (Immy.bot's wedge). We are the provisioning + hardening + desired-state + escrow layer, sold white-label to MSPs.

Sources

Competitive and best-practice research informing this plan: