Multi-tenant onboarding in days, not quarters: an India-headquartered MSSP

MSSPs have an architecture problem that most product vendors quietly do not solve. The MSSP is selling outcomes — detection, response, reporting — but the platforms they buy are designed for a single enterprise tenant. The MSSP workaround is to deploy one stack per customer, glue it together with a portal, and absorb the cost. The result, over four or five years, is a fleet of forked deployments that drift apart and require the MSSP to run a small platform-engineering team purely to keep them aligned.

This case study covers an India-headquartered MSSP that had reached the unsustainable end of that pattern. Forty-seven customers, forty-seven forked stacks, eight platform engineers spending most of their time on per-tenant maintenance rather than detection content, and a customer onboarding queue that had grown to six months because the platform engineers were the bottleneck. The CFO's question — "we are growing the book, why is gross margin shrinking?" — had a single-sentence answer: per-customer stack cost was growing faster than per-customer revenue.

The migration to a native multi-tenant graph took roughly five months end-to-end. The headline outcomes — onboarding eight weeks to four days, per-tenant infrastructure cost down 62%, analyst hours saved on context-switching at eleven hours per analyst per week — are not the deepest changes. The deepest change is that the MSSP can now sell things it could not previously sell, because the platform supports them. The clearest example is cross-tenant detection-pack publishing under explicit customer consent, which has become a differentiated commercial offering and is reported on separately at the end.

Before Netgraph

Six structural pains drove the decision.

• Forked deployments per customer. Each of the 47 customers had its own deployment of the SIEM stack, with its own tuning, its own detection content, its own version, its own infrastructure footprint. Twelve of the deployments were on customer infrastructure; thirty-five were in MSSP-owned data-centre capacity. Keeping them aligned at a content level was a recurring engineering exercise — and one that the MSSP was losing. The drift between the most-recently-onboarded customer and the oldest customer was, by detection-content audit, six versions and roughly 180 rules.
• Per-tenant database stack maintained by hand. Each tenant had its own database instances, its own backups, its own retention configuration. The platform engineering team had built a heroic deployment automation, but it still required an engineer-day per tenant per quarter to keep healthy. Across 47 tenants, that was twelve engineer-months per year of pure maintenance.
• No audited view-as-customer. When an analyst on the floor needed to investigate inside customer-A's tenancy, they used customer-A's credentials. When the next ticket came in for customer-B, they switched. This had two problems. Operationally, switching between consoles ate eleven minutes of context per pivot, and the analyst's day involved roughly forty such pivots. Compliance-wise, there was no clean audit trail showing which MSSP analyst had viewed which customer's data, under whose authority, for what reason.
• Onboarding lag costing deals. The MSSP's sales team had a six-to-eight-week onboarding commitment in the contract, and was hitting it about 70% of the time. Customers who needed faster onboarding either churned to competitors or, more painfully, accepted a "partial onboarding" deal that meant ramp-up over the first quarter at reduced contract value. The sales lead estimated the gross revenue impact at roughly 8% per year of bookings.
• Cross-tenant detection sharing was a legal headache. The MSSP's detection-engineering team built excellent content. Every new detection they wrote benefited the customer they wrote it for. Pushing that content to other customers required a per-customer agreement and a per-customer review. Most of the time it didn't happen. The content stayed in the originating customer's deployment and the rest of the book got it months later, if at all.
• Per-tenant licensing models were unaffordable. The two predominant SIEM platforms in the customer book priced per-tenant. The MSSP had two choices: pass the per-tenant cost through to the customer (which made smaller customers unviable), or absorb it (which made the smaller customers unprofitable). Neither was a good answer.

The MSSP's leadership had concluded — correctly — that they did not have a tooling problem, they had a substrate problem. A single-tenant platform stretched across 47 tenants was always going to lose money. The question was whether any platform on the market was actually built multi-tenant from the schema up, rather than retrofitted with a "tenant id" column.

Why Netgraph

The MSSP ran a structured evaluation of four platforms — two of their existing vendors' multi-tenant editions, one challenger, and Netgraph. The evaluation was unusually rigorous because the platform team's CTO had been burnt by previous "multi-tenant" claims that turned out to be cosmetic. The decisive criteria were architectural, not commercial.

1. Tenant identity is on every record, at the storage layer. Netgraph's graph schema requires a tenant_id property on every node and every edge. There is no path to write into the graph that bypasses it. Cross-tenant queries are physically prevented at the query planner, not the application layer. The CTO's evaluation note: "This is the first platform whose 'tenant boundary' I can defend in a customer security review without hedging."
2. Per-tenant key management and crypto-shredding. Each tenant has its own encryption key, managed in the MSSP's HSM with tenant-specific access policies. Off-boarding a customer means revoking the key, which makes the customer's data cryptographically inaccessible — a structural answer to the "what happens to my data when I leave" question that customers ask in every onboarding. Crypto-shred completes in minutes; physical purge follows the contractual schedule.
3. Audited view-as-customer. The MSSP analyst signs in with their own MSSP identity, then explicitly assumes a customer-tenant context. Every action taken under that context is logged as "[MSSP analyst X] acting as [customer Y, with role Z]" in a write-once audit log that both the MSSP and the customer can review. This solves both the operational problem (no more credential juggling) and the audit problem (a clean trail).
4. MSSP-tier pricing. Netgraph's commercial model has a native MSSP tier with capacity-based pricing pooled across tenants. The MSSP's smallest customers are no longer a cost-floor problem.
5. Detection-pack publishing with consent. Detection content is signed and versioned at the graph-schema level. Publishing a detection pack from tenant-A to tenants B through F, with explicit per-tenant consent, is a first-class platform workflow. This is what made the cross-tenant content-sharing problem solvable.
6. India residency and operational control. Important for the MSSP's BFSI customers, which form roughly 40% of the book. The MSSP's existing platform had to layer policy controls on top of a non-resident product; Netgraph's residency is structural.

The deciding moment was a technical workshop in week three of the evaluation, in which the MSSP's platform team attempted to deliberately break tenant isolation in three ways — direct API call with a forged tenant_id, query-injection across the GraphQL layer, and a constructed lateral query through the threat-intel enrichment edges. All three were blocked at the query planner with explicit "cross-tenant traversal not permitted" errors. The platform CTO described this in the post-meeting note as "the first vendor demo in five years where the answer to 'can you isolate tenants?' was a stack trace instead of a slide."

Implementation

The MSSP insisted on a phased migration rather than a flag day. The 47 customers were sorted into three cohorts by complexity: the 12 smallest (pilot), the next 23 (rolling migration), and the 12 largest (final wave with extra parallel-run). Total elapsed time from contract to "all 47 customers on Netgraph, legacy stacks decommissioned" was five months. The phased timeline is below.

Two observations worth flagging for any MSSP planning a similar move.

The onboarding template is the asset. The pilot's most valuable output was not the migrated customers; it was the per-customer onboarding template. By the end of phase 3, the template had reduced new-customer onboarding to four working days end-to-end, of which roughly half a day was the technical platform work and the rest was customer-side connector access and contractual paperwork. That four-day commitment has since become the headline of the MSSP's sales pitch.

The view-as audit log changed the SOC floor culture. Within three weeks of phase 2, the SOC floor had stopped using shared customer credentials entirely. Every action was traceable to a named MSSP analyst acting under a named customer authorisation. This was originally a compliance feature; in practice it became a quality-of-work feature. Analysts reported that being able to point to their own audited work-product changed how performance was discussed, and changed (positively) how the customer's security lead trusted them.

Outcomes

The metrics below cover the four-week baseline before the project began and a four-week steady-state window six months after the final cohort migrated. Per-tenant and per-analyst numbers are book-wide medians unless noted otherwise.

Two numbers warrant context.

The 10.5 hours per analyst per week is the largest single line of value in the change, and it is not infrastructure cost. Across 280 analysts, that is roughly 2,940 hours of recovered capacity per week. The MSSP did not lay anyone off; it used the recovered capacity to expand the threat-hunting bench from 11 to 28 analysts and to absorb the new commercial offering (detection-pack publishing) without additional hires. The CFO's preferred way to describe this is "we grew the book 18% in the six months after cutover without growing the floor."

The cross-tenant detection-pack publishing offering is the most strategically important outcome. The MSSP was previously unable to monetise its detection-engineering work beyond the per-customer contract. With consented publishing on a multi-tenant graph, the same detection-engineering hours produce content that lands across multiple customers in the same vertical, with full provenance and full opt-in. Three packs in the first quarter, consented by between five and eleven customers each. The customers value the cross-customer pattern visibility; the MSSP values the commercial leverage. Both sides win, and the platform makes the consent model auditable.

For five years we were a managed-SOC that happened to run forty-seven separate platforms. Now we are a managed-SOC that runs one platform with forty-seven tenants. That sounds like a technical change. It is actually a business model change.

What's next

Three workstreams are queued.

Vertical-specific detection guilds. The MSSP is formalising the cross-tenant pack-publishing model into named "guilds" — BFSI, pharma, IT-services-supplier — each with its own membership of consenting customers and its own contributing analysts. The structure is borrowed from open-source community models; the platform's content-signing model makes the provenance auditable in a way that traditional content-sharing arrangements were not. The MSSP expects to launch four guilds by Q4.

Customer-side co-pilot integrations. Several of the MSSP's larger customers want to operate alongside the MSSP analysts in the same graph, with their own internal SOC. The native multi-tenant model supports this with an "MSSP analyst plus customer analyst" combined access pattern, with separate audit trails per identity. The first three customers are being piloted in Q3.

SLA telemetry standardisation. Because all 47 customers are now on the same substrate, SLA telemetry — MTTD, MTTR, alert-volume trends — is comparable across the book for the first time. The MSSP is using this to revise its SLA model from a customer-by-customer commitment to a graded service-tier model with publishable benchmarks. The transparency is a sales asset; the comparability is an operational one.

The non-obvious lesson from this engagement: native multi-tenancy is not a feature. It is a precondition for a business model. An MSSP that retrofits multi-tenancy onto a single-tenant platform is competing with one hand tied. An MSSP that runs on a substrate designed multi-tenant from the schema up is selling something its competitors cannot, structurally, sell. The migration cost paid back inside a single fiscal year — and the strategic optionality, which the spreadsheet does not capture, is the larger story.

Sample case study. Composite of representative deployments; customer details anonymised.