Why the Microsoft Tenant Is the Right Trust Boundary

You use Entra ID for identity. Defender XDR for threat detection. Purview for data governance. Sentinel for SIEM. Intune for endpoint management. Azure Policy for infrastructure compliance. Every one of these systems operates inside your Microsoft tenant. You've defined Conditional Access policies, configured Private Link, deployed customer-managed encryption keys, and spent months hardening the boundary.

Then you send your compliance data, the evidence that all of this works, to a third-party SaaS that sits entirely outside that boundary.

The trust gap this creates isn't subtle. It's the same trust gap you'd object to if someone proposed running your SIEM outside your tenant, or your identity provider outside your control. Your governance data describes the effectiveness of every security control you operate. It belongs inside the same boundary that protects everything else.

The tenant boundary you already enforce

For Microsoft-stack organizations, the Entra ID tenant is the trust root. Every authentication decision, authorization policy, audit log, and compliance signal originates from or flows through this boundary. What's inside is yours. What's outside requires explicit trust delegation.

Here's what lives inside that boundary today:

• Identity and access: Entra ID, Conditional Access, Privileged Identity Management
• Threat detection: Microsoft Defender XDR (Endpoint, Identity, Cloud Apps, Office 365)
• Data governance: Microsoft Purview (Information Protection, DLP, Data Lifecycle)
• Security operations: Microsoft Sentinel (SIEM, SOAR, hunting)
• Endpoint management: Microsoft Intune (compliance policies, configuration profiles)
• Infrastructure compliance: Azure Policy (deny/audit/deploy-if-not-exists)
• Key management: Azure Key Vault (customer-managed keys, certificate lifecycle)

These systems produce the security truth about your organization. They generate evidence, enforce policies, and serve as the source of truth for your security posture.

Your GRC platform consumes that truth and organizes it into a compliance narrative: evidence mapped to controls, maturity scored, gaps identified. The question is simple: should the system assembling this narrative live inside the same boundary as the systems producing it, or outside?

The cost of crossing the boundary

When compliance data leaves your tenant boundary, three things happen.

You lose evidence provenance. Evidence generated inside your tenant (a Defender alert, a Purview classification label, an Azure Policy compliance state) has a provenance chain: specific service, specific time, specific context. When that evidence is extracted and stored externally, the provenance chain breaks. You're trusting the external system to faithfully represent what your tenant produced. An auditor can't independently verify it without going back to your tenant and comparing.

If the evidence stays inside your tenant, the provenance is continuous. The auditor traces from the GRC platform's assertion to the source record without crossing a trust boundary. Same tenant, same audit log, same chain of custody.

You introduce a new identity surface. Your GRC vendor maintains its own session layer, authorization model, and admin plane outside your Conditional Access policies. Your PIM-protected roles don't apply. Your risk-based authentication doesn't apply. The vendor's access controls are the only thing between their employees and your data.

Inside your tenant, Entra ID is the identity plane for everything. Same Conditional Access, same PIM workflows, same audit logs, same risk detection. No separate identity surface. No separate trust decision.

You fragment your audit surface. To answer "Who accessed our compliance data in the last 90 days?", you query two systems: your tenant's audit logs and your GRC vendor's audit logs. The vendor's logs may not capture the same detail or retain for the same duration. They definitely aren't correlated with your Sentinel instance.

If everything lives inside your tenant, the audit surface is unified. One Log Analytics workspace. One Sentinel instance. One set of detection rules. Anomalies detectable with the same tools you already operate.

First-principles reasoning: where should governance data live?

Start from first principles. Governance data has three properties:

1. It describes your security posture. It's derived from your security tooling.
2. It's consumed by auditors and boards. It must be trustworthy, meaning provenance and integrity must be demonstrable.
3. It's more sensitive than most operational data. A breach of governance data exposes your complete risk picture.

Given these properties, the optimal storage location has these requirements:

Every requirement points to the same answer: governance data should live inside your existing trust boundary. For Microsoft-stack organizations, that's the tenant.

This isn't a preference. It's a first-principles conclusion. The data is derived from tenant systems, consumed by people authenticated through tenant identity, and sensitive enough to warrant tenant-level protections. Why create gaps to fill with compensating controls when you can avoid the gaps entirely?

How Kyudo operates inside the tenant boundary

Kyudo is deployed inside your Microsoft tenant as a native workload. It doesn't sit adjacent to your tenant. It doesn't peer into your tenant through API connections. It lives inside it.

Identity: native Entra ID integration. Kyudo authenticates users through your Entra ID. No separate user database. No vendor-managed identity layer. Your Conditional Access policies apply. Your PIM-protected roles apply. Your sign-in risk detection applies. Access to Kyudo shows up in your Entra ID sign-in logs, your audit logs, and your Sentinel analytics rules. See the Microsoft integration page for the full integration surface.

Compute: your AKS cluster. The platform runs as containers on Azure Kubernetes Service in your subscription. You own the cluster. You define the node pools, network policies, and pod security standards. Kyudo's Helm charts are the application. Your infrastructure is the platform. You can inspect every container image against your own vulnerability scanning baseline before deployment.

Data: your storage, your keys. All compliance data, the Compliance Graph, evidence artifacts, control scores, risk assessments, lives in Azure storage resources inside your subscription. Encryption uses customer-managed keys in your Azure Key Vault. Your backup policies. Your geo-redundancy decisions. Your retention schedule. Nothing leaves your data boundary.

Network: Private Link throughout. The integrations that connect Kyudo to Defender, Sentinel, Purview, and Entra ID use Azure Private Link. Evidence collection happens over private endpoints on the Microsoft backbone. No public internet traversal. No vendor IP ranges in your firewall rules. No data in transit outside your network boundary.

Evidence sourced from the same stack. Kyudo collects evidence from the same Microsoft security tools that produce your security truth: Defender XDR alerts proving controls are operating, Sentinel incidents proving detection capabilities, Purview classification results proving data governance, Azure Policy states proving infrastructure compliance. The evidence stays inside the tenant from generation to consumption. The provenance chain never crosses a boundary.

Hub/spoke topology. The architecture uses a hub (core Kyudo services) and spokes (integration connectors to your security stack). All within your tenant. All within your network boundary. Subject to your own Azure Policy governance: naming conventions, required tags, denied public endpoints.

Zero vendor access. Kyudo has no network path into your tenant. No admin credentials. No support tunnel. No telemetry pipeline sending data out. You deploy it. You operate it. You update it. If you need vendor support, you provision temporary access through your PAM process, monitored by your logs, revocable at any time.

The counter-argument: "We don't want to operate our own GRC infrastructure"

This is the operational concern, and it's legitimate. Managed SaaS means the vendor handles patching, scaling, availability, and incident response. Running inside your tenant means your team has operational responsibility.

Three responses.

First, you already operate the infrastructure. You're running AKS clusters, managing Azure subscriptions, Key Vaults, storage accounts, and network configurations. Kyudo runs on the same stack. It's not a new operational domain. It's another workload on your existing platform.

Second, the operational surface is minimal. Upgrades are Helm upgrades. Scaling is Kubernetes autoscaling. Monitoring feeds into your existing Log Analytics workspace. The operational burden is comparable to any containerized application on AKS.

Third, the alternative is accepting the trust gap. Managed SaaS convenience costs you control over where governance data lives, who accesses it, and how it's protected. You're trading a trust problem for an operations problem, and operations problems have known solutions.

The 30-day deployment workshop includes knowledge transfer. Your team operates from day one with defined runbooks, monitoring dashboards, and escalation procedures.

The convergence point

Microsoft has built an integrated security stack (Defender, Sentinel, Purview, Entra ID, Intune, Azure Policy) that produces a comprehensive security signal from inside your tenant. The evidence your compliance program needs already exists inside your boundary.

The question is whether the system that organizes that evidence into audit-ready proof should also live inside the boundary, or sit outside it pulling data across through API connections.

The answer follows from the same logic that keeps your SIEM inside your tenant and your identity provider inside your tenant. Governance data is security-sensitive. It should live where security-sensitive data lives.

This is what sovereignty as a trust model means in practice. Not a deployment option. A first-principles architectural decision that governance data belongs in the same place as the systems it describes.

What to do before your next renewal

1. Diagram the boundary crossing. Draw your current architecture showing where governance data crosses your tenant boundary. How many API connections pull data out? How many integrations push evidence to an external system? Each crossing is a trust delegation you should be explicitly aware of.

2. Quantify the evidence provenance gap. For your last audit, how much evidence was presented from your GRC platform versus directly from source systems? For evidence that passed through an external GRC platform, can you prove it wasn't modified between source and presentation? If not, that's a provenance gap your auditor may eventually question.

3. Test your audit surface. Ask your security operations team: "If someone accessed our compliance data inappropriately, would we detect it?" If the answer requires checking a vendor portal's audit logs separately from your Sentinel instance, you have a fragmented detection surface.

4. Calculate the trust delegation. List every trust decision required by your current GRC architecture. "We trust the vendor's encryption." "We trust the vendor's access controls." "We trust the vendor's employee screening." Each is a compensating control for a gap that wouldn't exist if the data lived inside your tenant.

5. Evaluate the 30-day deployment path. You don't need to spend 12 months migrating. Kyudo's workshop-based deployment produces a production instance inside your tenant in 30 days. That's faster than most vendor-hosted platforms take to configure integrations.

Your tenant is your trust boundary. Everything inside it benefits from the security controls you've spent years building. Your governance data should be inside it too.

Book a demo to see Kyudo running inside a Microsoft tenant. We'll walk through the Entra ID integration, the Private Link connectivity, the evidence collection from Defender and Sentinel, and the zero-access operating model. Bring your Azure architect.