Running vulnerability management for one organization is hard enough. Running it for fifteen subsidiaries under a holding group, or for thirty client environments as a managed security service provider, is a different problem entirely. The findings, assets, scans and reports for every tenant have to live in one platform so your team works efficiently. At the same time, no analyst, no report and no scan result can ever cross a tenant boundary it does not belong to. That tension between operational consolidation and strict isolation is the defining challenge of multi-tenant security operations.
This article walks through how a vulnerability management platform built for many tenants actually handles that tension. We cover the tenant hierarchy that models holdings and subsidiaries, the scope filter that enforces isolation on every query, the role-based access control that decides who sees what, the owner resolution chain that routes work to the right team, and the identity layer that ties it all to a real person. The grounding throughout is PMAP, the enterprise vulnerability management platform and multi-vendor scan orchestrator, because every behavior described here maps to how the product is built.
If you are evaluating whether a platform can carry a multi-client or multi-subsidiary program without leaking data between tenants, this is the architecture you need to understand. For the broader picture of how a finding moves from intake to closed, see our pillar on the vulnerability management lifecycle. For how access control and audit evidence support a formal audit, see vulnerability management compliance.
One Console, Many Tenants: The MSSP Problem
A managed security service provider sells outcomes, not logins. The client wants to know that their critical vulnerabilities are being found, triaged and closed. They do not want to hear that the provider runs ten different consoles and copies spreadsheets between them. So the provider needs a single operational surface where analysts can pivot between client environments, run scans, assign findings and produce reports without re-authenticating into separate systems.
The catch is that the same single surface is a liability the moment isolation fails. If a junior analyst working on Client A can list assets from Client B, the provider has a contractual and legal problem, not a feature gap. If a scheduled report for one subsidiary pulls in findings from a sibling subsidiary, the holding group has leaked competitive and security-sensitive data inside its own walls. Multi-tenant vulnerability management lives or dies on the guarantee that consolidation never weakens isolation.
The same pressure applies to holding groups that are not service providers at all. A parent company with a dozen operating subsidiaries wants group-level visibility into total risk exposure, while each subsidiary security team needs to work only within its own perimeter. The parent security director wants roll-up numbers across the whole tree. The subsidiary analyst should never see a sibling subsidiary’s findings. Both the MSSP and the holding group need the same two things at once: one platform, many strictly separated tenants.
PMAP treats this as a structural requirement rather than a configuration option. The tenant boundary is the company, and it is wired into the data model and every query path. The rest of this article unpacks how that boundary is defined, enforced and operated.
Tenant Hierarchy: Holding and Subsidiaries
In PMAP, every tenant is a company. A company is a row in the platform’s core table, and virtually every other domain in the system, assets, projects, scans, findings, campaigns, teams and all reporting surfaces, references that company as its tenant key. There is no separate notion of an account or a workspace floating above the company. The company is the tenant.
The hierarchy is expressed with a single self-referencing relationship. Each company carries an optional parent reference. A company with no parent is treated as a holding company, the root of a tenant tree. A company that points to a parent is a subsidiary of that holding. This is enough to model a wide range of real structures: a holding group with many operating subsidiaries, an MSSP with one provider company at the root and a client company per engagement, or a flat set of independent tenants with no parent at all.
A few rules keep the hierarchy sane. A company cannot be its own parent. The platform blocks any update that would set a company’s parent to itself, which prevents a class of cycle bugs at the source. When you ask for a holding company’s subsidiaries, the platform first checks that the parent actually exists before listing its direct children, so a request against a deleted or invalid parent returns a clean not-found rather than an empty list that hides a mistake. List and detail responses resolve the parent’s name through a self-join, so a console can render “Subsidiary of Northwind Holdings” without a second round-trip to look the parent up.
Company creation is deliberately the most restricted operation in the whole domain. Adding a new tenant row is gated to platform administrators only. This is stricter than the general permission matrix would require, and that is intentional. Creating a tenant is the act of expanding the multi-tenant universe, and it belongs in the hands of whoever runs the platform, not whoever happens to hold an update grant on existing companies.
Activation and Deactivation Without Data Loss
Tenants are not always permanently live. A client engagement ends, a subsidiary is wound down, or a tenant is paused during a contractual dispute. PMAP models this with an active flag on the company rather than deletion. Deactivating a company soft-pauses it: the data stays intact and readable, but the platform blocks creation of new resources under that tenant.
The enforcement is centralized. Sibling services, asset, scan, project and campaign, call a shared activation gate before they create anything under a company. If the company is inactive, the gate refuses, so you cannot accidentally start a new scan or open a new project under a paused tenant. One deliberate exception keeps automated pipelines honest: scanner integrations bypass the gate so that in-flight ingestion is not interrupted by an administrative pause. The reasoning is that a deactivation is an administrative decision about new work, and you do not want it to silently drop scan results that were already on their way.
This pattern matters in a multi-tenant setting because tenants change state constantly. Activation gives you a clean, reversible way to freeze a tenant without destroying its history, which is exactly what you want when a client might come back or when a subsidiary’s data is still needed for audit purposes long after operations stop.
Scope Filter: The Multi-Tenancy Invariant
The hierarchy describes how tenants relate. The scope filter is how isolation is actually enforced, and it is the single most important mechanism in the entire multi-tenant story.
Every authenticated request carries an identity. From that identity, the platform builds a scope filter that lists exactly which companies the user is allowed to touch. Every list, export and facet query in every domain applies that filter as a hard constraint at the database layer. A repository does not return all findings and then hope the user interface hides the wrong ones. It returns only the findings whose company is in the allowed set, in the query itself.
This is the rule that the platform treats as non-negotiable. Forgetting to apply scope on any handler would leak cross-tenant data, so it is enforced as an invariant across every domain rather than left to individual developers to remember. Cross-tenant identifier access is rejected explicitly as well: if a user tries to read a specific finding by its identifier and that finding belongs to a company outside their scope, the request is refused rather than served.
Two details make this robust in practice. First, an unrestricted flag is reserved for platform administrators only. When that flag is set, the scope filter allows all companies, which is what lets a platform operator run the whole estate. Every other principal is confined to its assigned company or project scope, with no way to widen it from inside a request. Second, the default is deny. A scope filter that is not unrestricted and has an empty allowed set returns nothing. There is no accidental “empty filter means show everything” failure mode. If the platform cannot prove you are allowed to see a tenant’s data, you see nothing.
That default-deny posture is what separates a real multi-tenant platform from a single-tenant tool with a customer dropdown bolted on. The isolation is the floor, not a feature you opt into. For a deeper look at how these enforcement primitives also produce audit evidence, the identity, RBAC and multi-tenancy datasheet covers the surface in product terms.
Subsidiary Roll-Up Without Crossing Lines
Strict isolation would be useless on its own if a holding group could never see across its tree. The whole point of a holding structure is that the parent has legitimate visibility into its subsidiaries. So the platform has to let scope expand down a hierarchy without ever letting it leak sideways between siblings.
PMAP handles this through how scope is assigned, not by weakening the filter. A user granted access at a company scope can access that company and the projects under it. A holding-level operator is granted access across the relevant companies in the tree, so roll-up views aggregate the subsidiaries that operator is actually entitled to. The aggregation is built from the same allowed-company set that gates every other query, which means a roll-up across a holding tree is just a scope filter with several companies in its allowed set rather than one.
The sideways guarantee is the important half. A subsidiary analyst granted access to one subsidiary does not implicitly gain access to a sibling subsidiary, because the allowed set contains only the companies that analyst was granted, and nothing about a shared parent silently adds the siblings. The same property holds at the project layer, which we will return to under RBAC: a project-scoped grant does not open the owning company, precisely so that a consultant on one engagement cannot see other engagements at the same company.
For an MSSP, this is the mechanism that lets a senior provider engineer see across several client tenants for capacity planning while a client-facing analyst sees only the one client they support. For a holding group, it is what lets the group security director get a true total-risk number while each subsidiary team stays in its own lane. The roll-up is real, and it never becomes a side channel.
RBAC: Scoped Roles and Permissions
Tenant scope decides which data a user can reach. Role-based access control decides what they can do with it. In a multi-tenant platform these two questions are separate and both have to be answered on every request. PMAP’s RBAC domain owns the second one, and it is the category owner for how permissions are modeled across the platform.
A role in PMAP is a named bundle of permissions expressed as a matrix of entity types against actions. The platform defines a fixed catalog of entity types that cover the core nouns of vulnerability management, and a fixed set of actions that cover the verbs. Any combination of an entity and an action can be granted to a role, which gives you fine-grained control over exactly what a role can do without inventing a new role type for every nuance. A triage role might be able to view and update findings but not delete them. A reporting role might be able to view and export but not mutate anything. A platform-level role can do everything across every tenant. The exact matrix dimensions and the full enumeration of entities and actions are covered in our cluster article on the PMAP permission matrix; here the point is that the role is a configurable grid, not a fixed ladder of seniority.
System roles are protected. A role marked as a system role is seeded by the platform and cannot be modified or deleted through the API, which keeps a privileged baseline from being edited out from under the platform. The platform-admin system role receives wildcard authority, the unrestricted access we described in the scope section. Critically, naming a custom role “platform_admin” does not grant that authority. The platform checks both the system flag and the role name before short-circuiting to wildcard access, so you cannot escalate by cloning a name. That double check is the kind of defensive detail that matters most in exactly the multi-tenant scenario where a mistake leaks across clients.
Permission resolution is cached for speed but kept correct on changes. The platform resolves a user’s effective scope and permissions once and caches the result for a short window, then explicitly invalidates that cache whenever a grant or a role changes. A permission change to a role purges the cache for every user, because a role edit can affect anyone who holds it. The short cache window is a safety net for out-of-band edits rather than the primary correctness boundary, which is the explicit invalidation. The result is that an access change takes effect in seconds, which is what you want when you revoke a departing analyst or tighten a client’s permissions.
Scoped Grants and Time-Bound Access
A role on its own is abstract. It becomes real when it is granted to a user at a scope. PMAP’s user-access grant is the join between a user, a role and a scope, and the scope can be global, a single company, or a single project. This is where tenant isolation and permission modeling meet.
A global grant is unrestricted and is what a platform operator holds. A company grant lets the user act within that company and the projects under it. A project grant is the tightest: it confines the user to one project and, deliberately, does not open the owning company. That last property is worth dwelling on. If a project-scoped grant quietly added the owning company to the allowed set, a consultant hired for one assessment could enumerate every other project at that company. The platform refuses to do that. A project consultant sees the project they were granted and nothing else, which is exactly the isolation an MSSP needs when it brings in external testers for a single client engagement.
Grants can also be time-bound. Every grant can carry an optional expiry, after which it stops counting toward the user’s scope. The moment a grant lapses, it is excluded from the user’s resolved scope, and the platform caps the scope cache lifetime to the soonest upcoming expiry so that time-bound access actually ends on schedule rather than lingering until a cache window happens to roll over. A background process emits audit events as grants expire, so the expiry leaves a record. Time-bound access is the natural fit for a contractor who needs ninety days on a client environment, a vendor doing a fixed-window assessment, or any access that should never become permanent by forgetting to revoke it.
Granting and revoking are themselves audited. Every assignment and every revocation emits an audit event with the full context of who granted what to whom, at what scope. Revocation invalidates the target user’s cached scope immediately, so access ends the moment you remove the grant rather than at the next cache cycle. In a multi-tenant program where access changes are frequent and accountability matters, that audit trail and that immediacy are not optional niceties. They are how you prove, after the fact, exactly who could touch a given client’s data and when that changed.
Six-Branch Owner Resolution
Deciding who can see a tenant’s findings is access control. Deciding who should work a given finding is ownership, and in a multi-tenant estate with many teams across many companies, ownership cannot be a manual chore. PMAP resolves the owning team for an asset through a deterministic priority chain so that work routes itself.
A team in PMAP is a named group of users that owns assets, receives finding assignments, and carries routing metadata for tickets and notifications. Teams are scoped to the enterprise hierarchy through one of three modes. A team can operate within its own company only, across an explicit curated list of subsidiaries, or across an entire holding tree recursively. Those modes let you build, for example, a group-wide network operations team that owns network assets across every subsidiary, alongside an application team that is confined to a single company.
When an asset has no explicit owner, the platform resolves one by walking a fixed priority chain and returning on the first branch that matches:
- Explicit. If the asset already has an owner recorded directly, that wins. Nothing else needs to run.
- Group default. If the asset belongs to an asset group that carries a default owner team, that team owns it.
- IP scope or CIDR. If the asset’s address falls inside a location’s network range, the team tied to that range owns it. When multiple ranges match, the most specific range, the longest prefix, wins.
- Tag-based rule. A reserved branch for mapping asset tags to teams.
- Company default. If the asset’s company has a default owner team set, that team owns it.
- Fallback queue. If nothing above matched, the platform auto-creates a per-company default queue and assigns the asset there. This branch is idempotent and guarded so that concurrent resolution does not create duplicate queues.
The chain guarantees that every asset has an owner, even if it is just the company’s catch-all queue, so no finding ever lands nowhere. The branches move from the most specific signal, an explicit assignment, to the most general, a company-wide fallback, which means the most precise available information always wins. When several teams legitimately own one asset, the platform picks a deterministic primary, preferring teams over individual users because teams carry the ticket and notification routing metadata, which keeps downstream automation predictable.
Owner resolution is also where multi-tenancy is quietly enforced again. Linking an asset to a team that belongs to a different company is rejected outright as a cross-tenant link. You cannot, even by accident, make a team in one tenant the owner of an asset in another. The same boundary that gates queries gates ownership.
For a deeper treatment of how the tenant hierarchy and the resolution chain interact, see our cluster article on tenant hierarchy and owner resolution.
Identity: MFA, LDAP and Session Management
None of the scoping above means anything if the platform cannot trust who is on the other end of the request. Identity is the foundation that the whole multi-tenant model rests on, and PMAP treats it as the outer edge of the platform: the first thing touched on every session and the single source of the claims that every downstream scope check relies on. There is no secondary identity source.
Authentication supports both local and directory-backed login. Local accounts authenticate with an email and a password hashed per user. Directory accounts authenticate through an LDAP or Active Directory bind, with the directory configuration read live on every login so that an administrator’s change takes effect without restarting anything. For organizations that run identity centrally, which is most enterprises and most MSSPs, the directory path is the important one. New users can be auto-provisioned on their first directory login when that is enabled, with their role derived from a mapping of directory groups to platform roles. That group-to-role mapping is what lets you manage who is an analyst and who is an administrator from the directory you already operate, rather than maintaining a parallel access list inside the platform.
Multi-factor authentication is gated at the right point in the flow. After a password is verified, if the user has MFA enrolled, the platform does not issue real tokens. It returns an opaque challenge, and the actual access and refresh tokens are issued only after the time-based one-time code is confirmed. This means a stolen password alone is not enough to reach a single tenant’s data, which is exactly the bar a provider holding many clients’ security data needs to clear. The platform can also require MFA across all users as a platform-level flag, so an MSSP can mandate it rather than leave it to individual choice.
Sessions are tracked and revocable. On a session-aware login, the platform records a session row and rotates the refresh token’s identifier on every refresh, so a replayed or revoked token fails. Account lockout protects against brute force: a run of failed local logins locks the account for a cooldown window. Password changes enforce real complexity and a reuse history, and a change can optionally sign the user out of every other device. When an administrator deletes a user, the platform anonymizes the personal data in place and stamps a deletion marker rather than hard-deleting the row, which preserves the foreign-key integrity that audit trails depend on, and it revokes that user’s active sessions. There is even a guard that refuses to deactivate or delete the last remaining active platform administrator, so you cannot lock yourself out of your own platform.
Taken together, the identity layer gives a multi-tenant operator the controls a security buyer expects: centralized directory login, enforceable MFA, revocable sessions, brute-force protection and a clean deletion path that survives an audit. Every one of those controls feeds the same claims that the scope filter and RBAC then use to decide what the authenticated person can see and do.
Branding and Per-Tenant Reporting
Multi-tenancy is not only about isolation and access. It is also about presentation. When an MSSP delivers a report to a client, or a holding group delivers a board summary for one subsidiary, that artifact should look like it belongs to the tenant it describes, not like a generic export from a shared tool.
PMAP supports per-company branding at the tenant level. Each company can carry its own uploaded logo, stored in object storage, with the upload constrained to a sensible size limit and validated as a real image by inspecting the file’s content rather than trusting whatever the client claims the file type is. That logo then anchors the visual identity of that tenant’s surfaces and outputs. The validation detail matters more than it looks: accepting an arbitrary file because a client header said it was an image is a classic upload weakness, and the platform avoids it by sniffing the actual bytes.
Reporting flows through the same tenant boundary as everything else. A report generated for a company draws only on that company’s findings and assets, because the same scope filter that gates queries also gates the data a report is built from. There is no path where a report for one subsidiary quietly aggregates a sibling’s findings, because the report builder sees only the allowed-company set of whoever generates it. For an MSSP this is the difference between a deliverable a client can trust and a confidentiality incident waiting to happen.
The combined effect is that each tenant can be presented as its own branded program while sharing one underlying platform. The client sees their logo and their data. The provider sees one console. The isolation that protects the data also shapes the output.
How Routing a Scan to a Subsidiary Works
A concrete example pulls the pieces together. Suppose a scanner integration ingests results that include assets discovered on a particular network range. How does the platform know which tenant those assets, and the findings attached to them, belong to?
The answer runs through the company’s location and network model. Each company can define physical locations, and each location can carry one or more network ranges expressed as CIDR scopes. Those scopes are not decoration. They are the signal scanner integrations use to correlate a discovered asset back to a tenant. When ingestion sees an address inside a given range, the range tells it which company that asset belongs to, and the company is the tenant key that every downstream record inherits. Duplicate ranges inside a single location are rejected so that the mapping stays unambiguous.
Once the asset is attributed to the right company, the rest of the machinery we have described takes over without any extra wiring. The asset inherits the company’s tenant scope, so it appears only to users whose scope filter includes that company. Owner resolution runs the priority chain, and the IP-scope branch will frequently be the one that fires here, since the same network range that attributed the asset to a tenant can also map to the team that owns that range. The finding lands with the right owner, in the right tenant, visible only to the right people, and routed to the right team’s tickets and notifications. No analyst had to manually file the result under a client.
This is what “multi-tenant by construction” looks like in motion. The tenant boundary is not a label applied after the fact. It is derived from the network reality at ingestion and then carried, automatically and inescapably, through scope, ownership and delivery.
How PMAP Scales to Many Tenants
Step back and the shape of the system is clear. The company is the tenant, and it is the spine that every other domain hangs from. A self-referencing parent relationship turns flat companies into holding-and-subsidiary trees. A scope filter, applied as a hard database constraint on every query and defaulting to deny, makes isolation a structural invariant rather than a feature. RBAC layers configurable, scoped, time-bound and audited permissions on top of that isolation, so that what a user can do is as controlled as what they can see. Owner resolution routes work deterministically to the right team without crossing tenant lines. Identity, with directory login, enforceable MFA and revocable sessions, makes sure the platform always knows who it is talking to. Branding and tenant-scoped reporting let each tenant be presented as its own program.
The reason all of this holds together is that none of it is bolted on. Multi-tenancy is the foundation the platform was built on, which is why the tenant boundary shows up in the data model, in every query path, in ownership, in licensing quota and in reporting. A platform that added a customer dropdown to a single-tenant tool would have to remember isolation in every new feature. A platform built around the company as the tenant gets isolation for free in every new feature, because the scope filter is already in the path.
That is the practical promise for an MSSP or a holding group. You consolidate operations into one console and one team, you gain group-level or fleet-level visibility, and you never trade away the isolation that your contracts, your auditors and your clients depend on. The platform is licensed and quota-enforced as a single deployment through a signed entitlement, so capacity is governed centrally even as the tenant count grows. To put numbers and screens to all of this, read the identity, RBAC and multi-tenancy datasheet or the multi-tenant VM for MSSPs ebook, and run every client from one console.
To see how this multi-tenant foundation fits into the rest of a program, from intake through triage to closure, start with the vulnerability management lifecycle pillar, and for how scoped access and audit trails support a formal certification, read vulnerability management compliance. The control vocabulary here aligns with widely used references including the NIST RBAC model, NIST SP 800-207 Zero Trust Architecture, ISO/IEC 27001:2022 access control requirements, and CIS Controls v8 Control 6 on access control management.
Frequently Asked Questions
What makes a vulnerability management platform truly multi-tenant?
A truly multi-tenant platform enforces tenant isolation at the data layer on every query, not in the user interface. In PMAP the tenant is the company, and a scope filter derived from the authenticated user’s access is applied as a hard database constraint on every list, export and facet query. The default is deny: if the platform cannot prove a user is entitled to a tenant’s data, the query returns nothing. That structural isolation, rather than a customer dropdown over a single-tenant tool, is what lets one console safely serve many tenants.
How does PMAP keep a holding company’s subsidiaries isolated from each other?
Scope expands down a hierarchy but never sideways between siblings. A user is granted access to specific companies, and the resolved allowed-company set contains only those companies. Sharing a common parent never silently adds sibling subsidiaries to the set. A holding-level operator granted access across the tree can produce roll-up views, while a subsidiary analyst granted one subsidiary sees only that subsidiary. The same applies at the project layer: a project-scoped grant does not open the owning company, so a consultant on one engagement cannot enumerate other engagements at the same company.
Can access be time-limited for external testers and contractors?
Yes. A user-access grant can carry an optional expiry. Once a grant lapses it is excluded from the user’s resolved scope, and the platform caps the scope cache lifetime to the soonest upcoming expiry so time-bound access ends on schedule rather than lingering. Expiry emits an audit event, and both granting and revoking are audited with full context. This is the natural fit for an external tester who needs a fixed window on a client environment, since the access ends automatically without anyone remembering to revoke it.
Does PMAP support LDAP and multi-factor authentication for MSSP operators?
Yes to both. PMAP authenticates against LDAP or Active Directory with the directory configuration read live on every login, and it can auto-provision new users on first directory login with roles derived from a directory-group-to-role mapping. Multi-factor authentication is gated after password verification: an enrolled user receives an opaque challenge and real tokens are issued only after the one-time code is confirmed. MFA can be required across all users as a platform-level flag, so a provider can mandate it rather than leave it optional.
How are findings and assets automatically routed to the correct tenant and team?
Tenant attribution happens at ingestion. Each company defines locations with network ranges, and scanner integrations use those ranges to correlate a discovered asset back to a company, which is the tenant key every downstream record inherits. Team ownership is then resolved through a six-branch priority chain that returns on the first match, from an explicit owner through group, network range and company defaults down to a guaranteed per-company fallback queue. Linking an asset to a team in a different company is rejected as a cross-tenant link, so routing never crosses a tenant boundary.
What happens to a tenant’s data when an engagement ends?
A company can be deactivated rather than deleted. Deactivation soft-pauses the tenant: the data stays intact and readable, but the platform blocks creation of new resources under that company through a shared activation gate that sibling services check before creating anything. This keeps the tenant’s history available for audit while preventing new work. The activation is reversible, which matters when a client may return or when a wound-down subsidiary’s data is still needed long after operations stop.
How does PMAP prevent a report for one tenant from leaking another tenant’s data?
Report generation flows through the same scope filter as every other query. A report built for a company draws only on that company’s findings and assets, because the report builder sees only the allowed-company set of whoever generates it. There is no code path where a report for one subsidiary aggregates a sibling’s findings. Per-company branding lets each tenant’s reports carry their own logo, with the uploaded image validated by inspecting the file’s actual bytes rather than trusting the declared content type, so the deliverable is both isolated and correctly branded.
