In June, over 4.1 million individuals had their health information stolen from AdaptHealth, not because the company's perimeter failed, but because a third-party contractor's session was compromised through social engineering. The attacker used that contractor session to access AdaptHealth's cloud-based patient management and document storage systems.
This breach pattern is common in healthcare: attackers target the weakest authentication point in your vendor ecosystem, then use those credentials to access your most sensitive systems. If you manage incident response for a healthcare organization, you need a concrete plan to lock down vendor access before the next social engineering campaign hits your supply chain.
What You Need Before Starting
Before securing vendor access, you need visibility into what you're protecting:
Vendor inventory with access scope
List every third-party contractor with system access. For each vendor, document which systems they can reach, what data classifications they touch, and whether they access production environments. If you don't have this inventory, start with your VPN logs, SSO access records, and API key management console.
Authentication architecture map
Identify how each vendor authenticates: VPN with username/password, SSO federation, API keys, service accounts, or direct database credentials. Note which methods lack multi-factor authentication and which vendors share credentials across multiple users.
Incident response authority
Confirm you have the authority to suspend vendor access during an active incident without waiting for procurement or legal approval. Document this authority in your incident response plan with specific escalation paths for business-critical vendors.
Session monitoring capability
Verify your SIEM or cloud access logs capture vendor session activity with sufficient detail to detect anomalies: login times, source IPs, accessed resources, and data exfiltration volumes.
Step-by-Step Implementation
Step 1: Enforce phishing-resistant MFA for all vendor access
Standard SMS or authenticator-app MFA won't stop a determined social engineering attack. Deploy phishing-resistant authentication for every vendor access point:
- Configure your identity provider to require FIDO2 hardware keys or WebAuthn for vendor accounts.
- For VPN access, enable certificate-based authentication or SAML federation with hardware token requirements.
- Disable SMS and TOTP codes for vendor accounts in your identity provider settings.
- Set a 90-day deadline for vendors to adopt hardware keys; suspend access for non-compliant vendors after the deadline.
If a vendor claims they can't support hardware keys, reconsider whether they should have system access at all.
Step 2: Implement time-boxed, just-in-time access
Persistent vendor credentials create persistent risk. Replace standing access with time-limited sessions:
- Configure your privileged access management system to grant vendor access only when requested and approved.
- Set maximum session durations based on task type: 4 hours for routine maintenance, 8 hours for project work, 1 hour for emergency fixes.
- Require vendors to submit a ticket describing the specific task before access is granted.
- Automatically revoke access when the session expires; require a new approval for session extension.
For cloud systems, use your identity provider's temporary credential feature. In AWS, create cross-account roles with maximum session durations of 4 hours. In Azure, use Privileged Identity Management with eligible assignments, not permanent ones.
Step 3: Isolate vendor access to dedicated environments
Vendors should never access production systems directly. Create isolation layers:
- Deploy jump hosts or bastion servers for vendor access; configure these hosts to log all commands and screen activity.
- For cloud access, create separate vendor-specific IAM roles with read-only production access and full access only to non-production environments.
- Require vendors to perform work in staging environments, then have your staff promote changes to production.
- For vendors who must access production (monitoring tools, security platforms), restrict them to read-only roles and alert on any write operations.
Document the specific IP ranges vendors should connect from. Configure your firewall to block vendor authentication attempts from unexpected geographies or cloud providers.
Step 4: Deploy real-time session monitoring with automatic suspension
You need to detect compromised vendor sessions while the attacker is still active:
- Configure your SIEM to alert on vendor sessions that deviate from baseline behavior: unusual login times, new source countries, access to unfamiliar systems.
- Set up automated rules to suspend sessions that trigger high-risk indicators: bulk data downloads, access to credential stores, lateral movement to unrelated systems.
- Create a dedicated Slack or Teams channel where session anomaly alerts post in real-time.
- Assign an on-call engineer to monitor vendor session alerts during business hours.
For cloud environments, enable GuardDuty or equivalent threat detection with custom rules for vendor IAM roles. Configure these rules to automatically revoke temporary credentials when suspicious API calls are detected.
Step 5: Enforce network segmentation for vendor-accessible systems
The AdaptHealth breach spread from a compromised contractor session into patient management and document storage systems. Prevent this lateral movement:
- Place vendor-accessible applications in isolated network segments with strict firewall rules.
- Configure your cloud security groups to deny traffic between vendor-accessible systems and databases containing health information unless explicitly required.
- Implement application-layer access controls so vendor accounts can only reach the specific APIs or interfaces they need.
- Deploy a web application firewall in front of vendor-accessible applications with rules that block common post-compromise actions: SQL injection, command injection, path traversal.
Test your segmentation by attempting to access restricted systems from a vendor account. If you can reach systems beyond the vendor's documented scope, your segmentation isn't working.
Validation: How to Verify It Works
Run these tests quarterly to confirm your controls are functioning:
Phishing simulation against vendor accounts
Send realistic phishing emails to vendor contacts who have system access. Track whether they report the phish or attempt to enter credentials. Any vendor employee who submits credentials in a simulation should trigger a mandatory security review of that vendor relationship.
Unauthorized access attempt
Create a test vendor account and attempt to access systems outside its authorized scope. Your monitoring should detect and block the attempt within 5 minutes. If the attempt succeeds, you have a segmentation or monitoring gap.
Session hijacking drill
During a scheduled maintenance window, have a red team member take over an active vendor session (with the vendor's knowledge). Your session monitoring should detect the behavioral change and trigger an alert. Time how long it takes your team to notice and respond.
Access revocation test
Suspend a test vendor account and verify that all active sessions terminate immediately. Confirm the vendor can't reconnect using cached credentials or remembered sessions.
Maintenance and Ongoing Tasks
Monthly vendor access audit
Review your vendor access logs for dormant accounts. Any vendor account that hasn't authenticated in 60 days should be disabled. Require vendors to request reactivation with a documented business justification.
Quarterly vendor risk reassessment
For each vendor with system access, review whether they still need that access and whether their security posture has changed. Request updated SOC 2 reports or security questionnaires. Downgrade access for vendors whose risk profile has increased.
Annual vendor MFA key rotation
Require vendors to re-register their hardware keys annually. This ensures departing vendor employees can't retain access through keys they kept after leaving.
Continuous session baseline updates
Your SIEM's vendor session baselines will drift as vendors change their work patterns. Review and update baseline rules quarterly to reduce false positives while maintaining detection sensitivity.
The AdaptHealth breach shows that your vendor access controls are only as strong as your weakest contractor's resistance to social engineering. These steps won't eliminate vendor risk, but they will ensure that a compromised vendor session doesn't automatically mean a compromised patient database.
