I got an alert on a Saturday. A Cloud Solution Provider technician based in Canada had assigned Owner-level permissions at the subscription scope to a foreign-tenant group in our Azure environment. The activity itself was legitimate break-fix work. The access pattern was not.
Standing Owner-at-subscription access for a vendor principal violates the HIPAA Security Rule's minimum-necessary standard. It also creates an attribution problem: when a shared foreign-group principal performs an action in your tenant, you cannot tie that action to a specific individual without the vendor's cooperation. If their tenant is compromised, the attacker has the same standing access as their technicians.
This is not a hypothetical risk. It is the daily reality of running a healthcare cloud environment with vendor partnerships. CSP partners, managed service providers, and SaaS vendors all need some level of access to your tenant. The question is not whether to allow it. The question is how to detect when that access exceeds what is necessary and how to tighten it before an auditor finds it for you.
I built a detection pattern in Elastic SIEM that does this. Here is what it looks like.
The Problem with Vendor Access
Most healthcare organizations have at least one CSP partner managing licensing, billing, or infrastructure in their Microsoft tenant. The traditional access model is DAP, Delegated Access Privileges, which grants the partner tenant broad administrative access. The partner's technicians authenticate through their own tenant and operate under a shared group principal in your environment.
This creates three specific problems:
Over-privileged access. A technician who needs to reset a license does not need Owner-level access to the entire subscription. But DAP gives standing access at whatever scope was initially configured, and that scope tends to be broad because nobody wants to file a ticket every time a vendor needs to do something.
Attribution gaps. When actions are performed through a foreign-group principal, your audit trail stops at the group level. You can see that "ForeignGroup" assigned a role, but you cannot see which human being in the partner organization performed the action. HIPAA Security Rule 164.312(a)(2)(i) requires unique user identification. A shared group principal does not satisfy that.
Blast radius. If the partner's tenant is compromised, the attacker inherits whatever standing access the partner has in your environment. Broad DAP access means a compromise of a vendor tenant becomes a compromise of your production resources.
The Detection Pattern
The first thing I did was build a detection rule in Elastic SIEM scoped specifically to foreign-group and B2B guest write operations in the production resource group. This is tighter than the generic Azure RBAC rule that Microsoft ships. The generic rule fires on any role assignment change, which creates noise from legitimate administrative activity. My rule fires only when a foreign-tenant principal performs a write operation in the resource group that holds PHI-bearing workloads.
The rule triggers on three signals:
Role assignment changes by CSP technicians. When a partner technician assigns an administrative role, especially at subscription scope, the alert fires. The severity is based on the role assigned. Owner at subscription scope is high. Contributor at resource-group scope is medium. Reader is informational.
Service principal creation by partner technicians. CSP partners sometimes create service principals to automate their work. A service principal with broad Graph API permissions is a persistent access path that survives outside the partner's interactive session. Every new SP gets flagged for review.
Cross-tenant access from new geographies. If a partner technician signs in from an IP range that does not match their usual location, the alert fires. This catches both compromised credentials and unauthorized outsourcing of work to contractors the vendor has not disclosed.
What Happens When the Alert Fires
When the detection rule triggers, the alert lands in Elastic with the full context: which principal, what action, what scope, what IP, what timestamp. From there, the workflow is:
Triage. Is this expected partner activity? Most of the time, yes. A technician is doing legitimate work. But the alert documents it, which is the point. In a HIPAA audit, you need to show that you are monitoring vendor access and that you have a process for reviewing it.
Scope assessment. If the access is broader than necessary, it gets tightened. I migrate the partner from standing DAP access to GDAP, Granular Delegated Admin Privileges, with least-privilege roles scoped to the smallest resource group possible, with a maximum duration and an approval workflow.
Permission audit. I enumerate every role assignment and every resource held by the foreign-group principal. Anything that is not justified gets removed. For service principals, I document the Graph API permission set and revoke anything that is not essential.
Conditional Access enforcement. I require MFA and named-location conditions for all CSP-partner sign-ins. No exceptions. If the vendor cannot meet those requirements, they do not get interactive access.
The Cross-Tenant Audit Pipeline
Detection is only useful if the logs are flowing. One of the first things I verify after deploying a new detection rule is that the relevant log source is reaching Elastic.
For vendor access monitoring, that means Entra ID cross-tenant access activity logs. These logs capture when a B2B guest or foreign-group principal performs an action in your tenant. I run a sample query after deployment to confirm that partner events are showing up. If the pipe is broken, the detection rule is useless and I need to fix the ingestion before the rule means anything.
Why This Matters Beyond One Alert
That Saturday alert was not a security incident. It was a configuration drift. A partner technician needed to do work, used the access they had, and created a standing permission that exceeded what they needed. That happens constantly in cloud environments. It is not malicious. It is just how people work when the path of least resistance is a broad permission scope.
The detection pattern catches that drift in real time instead of discovering it during an audit or after a breach. It creates a documented review trail for every vendor action in the production environment. And it gives you the ammunition to push vendors toward least-privilege models because you can show them exactly what access they are using and what they are not.
The Takeaway
If you run a healthcare cloud environment with vendor partnerships, you need vendor access detection in your SIEM. The generic rules that cloud providers ship are not specific enough. You need rules scoped to your production resource groups, tuned to the access patterns of your specific partners, and backed by a log pipeline that you have verified is actually working.
The HIPAA Security Rule does not care whether your vendor is the one who over-privileged themselves. It cares whether you knew about it and what you did to fix it. Build the detection. Verify the pipeline. Document the review. That is how you turn a vendor access risk into a routine operational practice instead of an audit finding.
Top comments (0)