Azure tenant-local security management changes the NHI trust model

At a glance

What this is: This is an analysis of tenant-local Azure security deployment, with the key finding that keeping security data and controls inside the tenant reduces third-party exposure and broadens operational transparency.

Why it matters: It matters because IAM, NHI, and PAM teams have to decide whether delegated access, data residency, and auditability are acceptable when security tooling touches identity state and configuration logs.

By the numbers:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Senserva's analysis of tenant-local Azure security management with Azure Lighthouse

Context

Azure Lighthouse changes the governance question around security tooling. Instead of asking whether a vendor can manage controls remotely, the more relevant question is whether identity and security state should ever leave the tenant in the first place when the platform is handling configuration, logging, and delegated access.

For MSPs and MSSPs, that shifts the conversation from convenience to control plane design. Tenant-local deployment can reduce data-sharing friction, simplify residency arguments, and narrow the blast radius of a compromise, but it also introduces new operating expectations around access boundaries, update governance, and audit clarity.

The primary issue here is not product capability alone. It is whether modern identity security tooling should preserve tenant sovereignty while still supporting scale, especially when the same environment may need to support Entra ID, Microsoft Defender, Sentinel, and third-party oversight.

Key questions

Q: How should security teams decide whether identity tooling belongs inside the tenant or in a shared cloud?

A: The decision should start with custody of identity state. If the tool processes audit logs, configuration records, or access policies that a customer must keep under direct control, tenant-local deployment is usually the safer governance model. Shared cloud operations can still work, but only when data residency, segregation, and delegated access are tightly documented and reviewed.

Q: Why does delegated Azure access create governance risk in MSP and MSSP models?

A: Delegated access is powerful because it scales administration across tenants, but it can also behave like standing privilege if scopes are broad or never reviewed. The risk is not the concept itself, but the control gap around duration, visibility, and offboarding. Without lifecycle discipline, a delegate can outlive the operational need and widen the blast radius.

Q: What do security teams get wrong about agentless identity scanning?

A: Teams often assume that because a tool installs nothing on the workload, it is automatically low risk. In reality, agentless scanning shifts the control burden to API permissions, token governance, and logging integrity. If those controls are weak, the tool still has privileged visibility and can create a governance gap even without an installed agent.

Q: Who is accountable if a tenant-local security tool exposes identity data?

A: Accountability depends on custody and delegation. If the data remains inside the tenant, the customer retains primary governance responsibility, while the operator is accountable for the delegated permissions and the way it handles the environment. If the tool centralises data outside the tenant, the accountability chain becomes broader and harder to prove during audit or incident review.

Technical breakdown

Tenant-local deployment versus shared vendor control plane

Tenant-local deployment keeps security data, policy state, and operational artifacts inside the customer Azure tenant instead of pushing them into a shared vendor-hosted environment. In practice, that changes where trust is placed. The tenant becomes the control boundary, while the vendor or MSP interacts through delegated access patterns such as Azure Lighthouse. This matters because identity and security tools often need broad read access across logs, configuration, and policy objects. If those objects are copied or centralised elsewhere, the governance burden expands into data residency, separation of duties, and cross-customer exposure risk.

Practical implication: treat the tenant as the primary trust boundary and review whether any security tool actually needs to move identity state outside it.

Azure Lighthouse and delegated access in multi-tenant operations

Azure Lighthouse is designed to let one operator manage multiple Azure tenants through delegated access rather than per-tenant manual sign-in. That improves scale for MSP and MSSP workflows, but it also means the delegated relationship itself becomes part of the attack surface. The security question is not whether remote management is possible, but which permissions are granted, how they are bounded, and whether the delegate can see more than it needs. For identity teams, that makes access scoping, approval workflows, and customer-by-customer segregation central design concerns.

Practical implication: review delegated roles tenant by tenant and remove any permissions that are broader than the operational task requires.

Agentless scanning, Microsoft Graph, and identity visibility

Agentless security tools use APIs and service endpoints to query identity and configuration state without installing software on every workload. In this model, Microsoft Graph, Defender, Sentinel, and Entra ID become the observation surface. That gives teams broad visibility, but it also concentrates value into API permissions, token handling, and audit logging. If the tool can inspect drift, compliance, and access policy without agents, then the main question becomes whether those API-based reads are tightly governed and whether the resulting insights stay attributable to the right tenant and operator.

Practical implication: audit API permissions and logging paths as carefully as you would a privileged admin account.

NHI Mgmt Group analysis

Tenant-local security tooling is really a control-boundary decision, not a deployment preference. When security state stays in the customer tenant, the organisation preserves clearer ownership of logs, policies, and configuration history. That matters because identity governance fails quickly when telemetry and control evidence are scattered across external environments. The practitioner takeaway is to judge tools by where they store trust, not by how quickly they install.

Delegated access solves scale only when the delegation itself is tightly bounded. Azure Lighthouse can support multi-tenant operations, but every delegated relationship creates a governance obligation around scope, review, and offboarding. If the MSP can inspect too much, the customer loses segregation. If the delegation is too broad for too long, the organisation has recreated standing privileged access in another form. The implication is to treat delegated administration as a lifecycle object, not a permanent trust grant.

Identity security tools are becoming part of the identity control plane, so they should be governed like one. When a platform reads Entra ID, Sentinel, Defender, and Microsoft Graph from within the tenant, it is no longer just a reporting layer. It is participating in the security decision chain. That means auditability, role scoping, and configuration drift monitoring should sit under the same governance expectations as other privileged identity systems. Practitioners should classify these tools as control-plane infrastructure, not lightweight add-ons.

Vendor-hosted aggregation increases the blast radius of identity telemetry, even when the product is operationally convenient. Centralised dashboards can simplify oversight, but they also create a single place where cross-customer data and security state concentrate. For MSPs and MSSPs, that concentration may conflict with residency obligations, customer assurance requirements, and separation between tenants. The practitioner conclusion is simple: if the tool aggregates identity state across customers, the security case must explain why that concentration is acceptable.

Tenant sovereignty is becoming a design requirement for identity security in regulated environments. The article’s GDPR, HIPAA, and FedRAMP framing reflects a broader market direction. Security teams are increasingly expected to prove that sensitive identity and configuration data stays under customer control, not just that it is encrypted in transit. The implication for programmes is to prefer architectures that minimise third-party custody of identity evidence and preserve tenant-level accountability.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how thin identity oversight still is in many environments.
• The NHI Lifecycle Management Guide helps teams move from visibility gaps to lifecycle control when identity state must stay inside the tenant.

What this signals

Tenant sovereignty is becoming a practical design criterion for identity security programmes. When identity and security telemetry stay inside the customer environment, teams preserve clearer custody over audit evidence, access history, and configuration drift. That model aligns naturally with the NIST Cybersecurity Framework 2.0, especially when governance and protective controls have to be demonstrated rather than assumed.

Identity control planes are now part of the security stack, not just observability tooling. With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, the operational question is whether your delegated tooling can inspect privileged state without becoming a new source of overreach. Practitioners should watch for broadened API permissions, uncontrolled aggregation, and weak offboarding of delegated access.

Tenant-local architectures are likely to become the default expectation in regulated MSP and MSSP deployments. The more identity evidence a platform keeps in the customer tenant, the easier it is to defend residency, auditability, and separation of duties. Teams should expect procurement, risk, and assurance reviews to focus less on convenience claims and more on where the trust boundary actually sits.

For practitioners

• Map your trust boundary to the tenant first Document which identity and security objects must remain inside the Azure tenant, including configuration state, audit logs, and policy records. Use that boundary to decide whether a security tool can be operated safely through delegated access or whether it creates unnecessary third-party custody.
• Review delegated access as a lifecycle control Treat Azure Lighthouse permissions as time-bound governance objects. Revalidate the roles, scopes, and offboarding process for each customer tenant so the delegated operator cannot retain access beyond the business need.
• Audit API permissions and telemetry paths Confirm that Microsoft Graph and related API access is limited to the minimum needed for scanning, reporting, and drift detection. Verify where logs are stored, who can query them, and whether any cross-tenant aggregation is unavoidable.
• Test the blast radius of compromise scenarios Model what an attacker could reach if a delegated admin credential, API token, or dashboard account were exposed. Compare tenant-local deployment with a shared control plane to see which architecture reduces cross-customer exposure most effectively.

Key takeaways

• Tenant-local deployment changes the governance question from operational convenience to custody of identity and security state.
• Delegated Azure access can scale multi-tenant administration, but only if scope, duration, and offboarding are treated as lifecycle controls.
• Identity security tools that inspect Entra ID, Graph, Sentinel, and Defender should be governed as control-plane infrastructure, not lightweight dashboards.

Key terms

• Tenant-local deployment: A deployment model where data, policy state, and operational artefacts remain inside the customer’s Azure tenant. It reduces third-party custody of identity and security evidence and is especially relevant when compliance, auditability, or separation of duties must be preserved.
• Delegated access: A permission model that lets one operator manage another tenant or environment without taking direct ownership of the credentials. It is useful for scale, but it must be bounded by scope, review, and offboarding so it does not become standing privilege by another name.
• Control plane: The layer where systems make administrative and security decisions, such as policy enforcement, logging, access approval, and configuration changes. In identity security, the control plane is where governance lives, so moving it outside the tenant changes the trust model materially.
• Agentless scanning: A method of collecting security and identity posture data through APIs rather than by installing software on each workload. It can reduce operational friction, but the security burden shifts to API permissions, token handling, and the integrity of the resulting audit trail.

What's in the full article

Senserva's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step deployment flow for Azure Lighthouse onboarding across customer tenants
• Specific Microsoft Graph, Defender, Sentinel, and Entra ID integration points used by the platform
• Packaging and update mechanics for tenant-local instances, including CI/CD rollout behaviour
• Tenant UI lockdown and access restriction details for operator-only administration

👉 Senserva's full post covers the deployment model, integration scope, and tenant-local control details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.