When ShinyHunters leaked 7.1 million records from Baxter International in August 2026, the attack vector wasn't a zero-day exploit or a sophisticated supply chain compromise. Baxter detected unauthorized activity in third-party applications, the same vulnerability that healthcare organizations often leave exposed. ShinyHunters gave Baxter until August 17 to negotiate, then dumped the data publicly when talks stalled.
You're running a similar risk right now. Every SaaS tool, vendor portal, and integrated platform in your environment represents a potential breach point. Here's how to secure them before you're the next case study.
What You Need Before Starting
Access inventory and ownership mapping
You can't secure what you don't know exists. Compile a complete list of every third-party application that touches your data. This isn't just your formal vendor list. Include:
- Shadow IT tools your teams adopted without procurement
- Legacy integrations nobody remembers configuring
- Partner portals with shared credentials
- Cloud services connected via OAuth tokens
Assign a business owner to each application. That owner is accountable for knowing what data flows through it and who has access.
Current authentication and authorization architecture
Document how users authenticate to each third-party app. Are they using SSO with your identity provider, or standalone credentials? Map which applications support SAML or OIDC, and which still rely on username/password combinations that bypass your centralized controls.
Identify applications that don't enforce multi-factor authentication. These are your immediate priorities.
Data classification framework
You need to know what you're protecting. If you're handling protected health information under the Health Insurance Portability and Accountability Act (HIPAA), classify which third-party apps process, store, or transmit it. Do the same for financial data under the Gramm-Leach-Bliley Act (GLBA) or personal data under the General Data Protection Regulation (GDPR).
This classification drives your control requirements. An HR tool processing employee Social Security numbers requires different controls than a marketing platform tracking website clicks.
Step-by-Step Implementation
Step 1: Enforce identity federation across all third-party applications
Eliminate standalone credentials wherever possible. Configure SAML 2.0 or OIDC integration between your identity provider and each third-party application. This gives you centralized visibility and control over who can access what.
In your identity provider, create application-specific groups that map to roles within each third-party tool. Apply the Principle of Least Privilege: grant only the minimum access required for each user's job function.
For applications that don't support federation, implement a privileged access management solution to rotate credentials automatically and enforce approval workflows for access.
Step 2: Implement Just-in-Time Access for administrative privileges
Administrative accounts in third-party applications are high-value targets. Instead of granting permanent admin access, configure time-bound elevation that expires after a defined period.
Set up approval workflows requiring manager or security team sign-off before granting elevated privileges. Log every elevation request with business justification. When the task is complete, revoke the access automatically.
Step 3: Deploy continuous monitoring for third-party application activity
Configure your SIEM to ingest logs from every third-party application. Focus on:
- Failed authentication attempts (five or more in ten minutes indicates credential stuffing)
- Bulk data exports or API calls outside normal usage patterns
- New OAuth tokens or API keys generated
- Administrative privilege escalations
- Access from unfamiliar geographic locations or IP ranges
Set up alerts for anomalous behavior. If a user who normally accesses your CRM from New York suddenly logs in from Romania at 3 AM and exports 50,000 records, you need to know immediately.
Step 4: Enforce network segmentation and conditional access
Don't allow third-party applications to be accessible from anywhere on the internet. Implement conditional access policies that restrict access based on:
- Device compliance state (managed devices only)
- Network location (corporate network or approved VPN)
- Risk level (block access if the user account shows signs of compromise)
For particularly sensitive applications, require access through a secure gateway or bastion host that you control.
Step 5: Conduct quarterly access reviews
Every 90 days, send each application owner a list of who has access to their third-party tools. They must confirm that each user still requires access for their current role.
Revoke access for anyone who has changed roles, left the organization, or no longer needs the tool. Don't wait for the user to request removal. Automated deprovisioning should trigger when HR updates someone's status in your system of record.
Validation: How to Verify It Works
Test your federation configuration
Attempt to access each third-party application using credentials that exist in the application but not in your identity provider. The login should fail. If it succeeds, you've still got a backdoor that bypasses your controls.
Verify that when you disable a user account in your identity provider, they immediately lose access to all federated applications. There shouldn't be a delay.
Simulate an attack scenario
Create a test account and attempt to:
- Export large datasets in a single session
- Access the application from a suspicious IP address
- Generate new API credentials without approval
Your monitoring should detect and alert on each of these activities within minutes, not days.
Review your incident response readiness
If a third-party application notifies you of unauthorized activity, can you quickly determine:
- What data was accessible through that application?
- Who had legitimate access in the past 90 days?
- Whether any exported data or API calls occurred before you detected the breach?
Run a tabletop exercise with your Computer Security Incident Response Team. Give them a scenario: "Our CRM vendor just notified us of suspicious API activity on our account." Time how long it takes them to pull logs, identify affected data, and initiate containment.
Maintenance and Ongoing Tasks
Monthly: Review new third-party application requests
When teams request new SaaS tools, evaluate them against your security requirements before procurement approves the spend. Can the vendor support SAML or OIDC? Do they provide audit logs you can ingest? What's their breach notification process?
Reject applications that can't meet your baseline controls, or require the business owner to accept the risk formally.
Quarterly: Update your third-party risk register
Re-assess each vendor's security posture. Request updated SOC 2 Type II reports or ISO/IEC 27001 certificates. If a vendor suffered a breach since your last review, escalate them for additional scrutiny.
Track vendors who refuse to provide attestations or who show declining security maturity. These are candidates for replacement.
Annually: Penetration test your third-party integrations
Hire an external firm to test your third-party application security. Give them valid credentials and ask them to see how much data they can exfiltrate without triggering alerts.
The results will be uncomfortable. Use them to refine your monitoring rules and access controls.
Continuously: Monitor threat intelligence for your vendors
Subscribe to feeds that track active threat groups and their targeting patterns. When Health-ISAC issued an alert about ShinyHunters in July 2026, that was your signal to review whether your third-party applications could withstand the group's tactics.
If a vendor appears on a breach disclosure list, immediately review your integration with them. Assume your data may be at risk and verify your containment options.
The ShinyHunters breach at Baxter shows what happens when third-party application security becomes an afterthought. You won't prevent every attack, but you can make your environment harder to compromise than the next target on the list.
