Cloud Device Labs: Security and Compliance

Your app handles patient health records. Credit card numbers. Bank account balances. Social security numbers.

Now here’s an uncomfortable question: Where does that data go when you run your automated tests?

If you’re using a cloud device lab like BrowserStack, Sauce Labs, or AWS Device Farm, the answer is: third-party servers you don’t control, on devices shared with thousands of other companies, with cleanup processes that even the providers admit aren’t foolproof.

For fintech and healthcare teams requiring HIPAA or PCI DSS compliance, cloud device lab security isn’t just a technical concern—it’s a compliance nightmare waiting to happen.

The Hidden Risk in Your Testing Pipeline

Let’s start with what the cloud device lab providers actually say in their own documentation. These aren’t accusations—they’re direct quotes.

What AWS Device Farm Says About Data Security

From AWS Device Farm’s official security documentation:

“Device Farm’s physical mobile device testing data is not encrypted at rest.”
— AWS Device Farm Security Documentation

“It is possible for data to persist between sessions in some cases, especially if you make use of the device system outside the context of your app.”
— AWS Device Farm Security Documentation

“We recommend that you do not enter sensitive information (for example, Google account or Apple ID), personal information, and other security-sensitive details during your automated test and remote access sessions.”
— AWS Device Farm Security Documentation

And here’s the kicker:

“AWS Device Farm is not in scope of any AWS compliance programs.”
— AWS Device Farm Compliance

That’s right. The service you might be using to test your HIPAA-regulated healthcare app or PCI DSS-compliant payment flow explicitly tells you it’s not covered by compliance certifications.

What Sauce Labs Acknowledges

According to Sauce Labs Trust Center, they acknowledge similar limitations. Their cleanup process runs after each session to reset devices, but they note: “If we encounter any issue during the cleaning process, or we fail to clean the device, we put those devices aside for manual inspection.”

Translation: cleanup can fail. And when it does, your data sits on that device until someone manually reviews it.

The Third-Party Breach Epidemic

You might think: “These are major providers. They have security teams. What’s the real risk?”

Let’s look at the numbers.

Healthcare Breach Statistics

• 275 million healthcare records were compromised in 2024 alone—equivalent to 80% of the U.S. population
• 41% of healthcare data breaches in 2024 originated from third-party vendors
• Over 80% of stolen protected health information came from third-party vendors, not hospitals
• The average healthcare data breach costs $7.42 million (IBM Cost of Data Breach Report, 2025)

Fintech Breach Statistics

• Finance accounted for 27% of all global breaches in 2023
• 41.8% of breaches impacting top fintech companies originated from third-party vendors (SecurityScorecard, 2025)
• Average cost per fintech breach: $5.9 million

The pattern is clear: third-party vendors are the primary attack vector. Not your internal systems. Not your production environment. The vendors you trust with your data.

BrowserStack learned this lesson in 2014 when attackers exploited an unpatched ShellShock vulnerability to access their AWS infrastructure. The hackers copied data from a table containing “email addresses, hashed passwords, and last tested URLs” before sending fake shutdown notices to 5,000 users.

That was a decade ago. The threat landscape has only intensified since.

What Compliance Actually Requires

Let’s be specific about what regulations demand—because “we use a major cloud provider” isn’t a compliance strategy.

HIPAA (Healthcare)

The Health Insurance Portability and Accountability Act requires:

• PHI must be encrypted at rest and in transit
• Any third-party handling PHI must sign a Business Associate Agreement (BAA)
• Organizations must implement technical safeguards in all environments—including test environments

Here’s the problem: AWS Device Farm explicitly states physical device testing data “is not encrypted at rest.” And it’s “not in scope of any AWS compliance programs.”

If your test flows touch anything resembling PHI—even test accounts with realistic-looking data—you may be exposing yourself to regulatory risk.

84% of FDA-approved medical health applications have been found to have security threats that might expose sensitive data. And 50% of top mHealth apps store data in the cloud, creating what researchers call “a serious risk to users’ data privacy and security.”

PCI DSS (Fintech)

The Payment Card Industry Data Security Standard is unambiguous:

“No cardholder data in non-production environments. Period.”

That includes test environments. If your payment flow tests use card number formats—even test card numbers in the standard 16-digit format—you need to ensure those test environments meet PCI DSS requirements.

Cloud device labs running on shared infrastructure where “data can persist between sessions” don’t exactly inspire confidence.

PCI DSS 4.0 requirements include:

• Encrypt cardholder data at rest and in transit
• Restrict data access to business needs
• Regularly monitor and test security systems
• Maintain vulnerability management programs

When your test data flows through a third-party’s shared device pool, how do you demonstrate compliance with these requirements during an audit?

GDPR (Everyone Serving EU Users)

The General Data Protection Regulation doesn’t care if it’s “just test data.”

The Spanish Data Protection Authority states explicitly: “Test environments sometimes process personal data without having applied the appropriate technical and organisational measures according to the risk to the rights and freedoms of data subjects.”

The penalties are real:

• LinkedIn: €310 million fine
• Meta: €251 million penalty in 2024

Both for inadequate handling of personal data—including in non-production environments.

Even before GDPR, the German Federal Data Protection Act prohibited using personal data for testing purposes. GDPR raised the stakes to up to €20 million or 4% of global annual turnover.

The Test Data Illusion

You might be thinking: “We use synthetic test data. We’re fine.”

Are you sure?

Consider what your test flows actually contain:

• Login flows: Test credentials that mirror production patterns
• Payment flows: Test card numbers that follow real card formats
• User profiles: Test data with realistic names, addresses, birthdates
• Health data: Symptom entries, prescription lookups, appointment details
• Session data: OAuth tokens, API keys, session identifiers

Even “synthetic” data often contains patterns that could identify or be combined with real user information. And your test automation scripts themselves may contain configuration data, API endpoints, and credential patterns that you wouldn’t want competitors—or attackers—to access.

Here’s what one fintech data protection officer discovered: their test environments—used by 400+ developers, contractors, and offshore teams—contained 18 months of unmasked customer data. A single GDPR erasure request exposed the truth: production systems deleted records within hours, but test databases retained that data indefinitely.

The problem isn’t just what you intentionally put in test data. It’s what accumulates over time in environments you don’t fully control.

Real-World Consequences: 2024 Breach Examples

This isn’t theoretical. Here’s what happens when third-party testing vendors get compromised:

Change Healthcare (2024): A ransomware attack on this healthcare payment processor exposed an estimated 190 million records—the largest healthcare breach in history. The attack vector? Third-party infrastructure.

Kaiser Permanente (2024): Personal health information for 13.4 million members was shared with third-party entities through tracking code embedded in their website and mobile app. The exposed data included names, IP addresses, symptom searches, and account activity.

Bank of America (2024): Customer data was exposed through a breach at Infosys McCamish Systems, a third-party data processor. Compromised information included names, Social Security numbers, and account details.

Finastra (2024): This fintech giant serving 8,000 clients learned hackers had accessed their third-party Secure File Transfer Platform, exfiltrating corporate data, accounting records, and legal agreements.

The pattern repeats: organizations get breached through their vendors, not their own systems.

What Makes Cloud Device Labs Risky

Let’s be specific about the structural risks:

1. Shared Infrastructure

Your tests run on the same physical devices as thousands of other companies. Even with cleanup processes, you’re trusting that:

• The cleanup runs successfully every time
• No data persists in device memory, caches, or storage
• The next company’s tests can’t access residual data
• No malicious actors have compromised the shared environment

2. Data Transit

Your test data travels from your CI/CD system to the provider’s cloud, gets processed on shared devices, and results flow back. That’s multiple transit points where data could be intercepted, logged, or cached.

3. Cleanup Uncertainty

Even providers who take cleanup seriously acknowledge it can fail. Sauce Labs puts devices aside for “manual inspection” when cleanup encounters issues. AWS Device Farm notes data “can persist between sessions.” What happens to your data during those edge cases?

4. Compliance Gaps

As AWS Device Farm explicitly states, physical device testing is “not in scope of any AWS compliance programs.” If your compliance officer asks for certification that your test environment meets HIPAA or PCI DSS requirements, what do you show them?

5. Third-Party Access

Cloud device labs have employees who maintain the infrastructure, debug issues, and respond to support tickets. How many people potentially have access to devices where your test data might persist?

Cloud vs Private Device Lab: Risk Comparison

The Zero-Trust Alternative

There’s a reason banks and healthcare systems use on-premises or private device cloud solutions for testing. When you control the hardware, you control the risk.

On-premise device labs give you:

• Complete control over device lifecycle
• No data transit to third parties
• Full compliance certification scope
• Guaranteed cleanup processes you design

The traditional problem with on-premise labs has been cost and complexity. Enterprise solutions start at $50,000+ annually and require dedicated infrastructure teams.

But there’s a middle path: peer-to-peer device clouds that use your own devices.

With this architecture:

• Your devices: You own the hardware, you control what’s installed
• Your network: Data flows directly between your machine and your devices
• Your data: Nothing touches third-party servers
• Your compliance: Your infrastructure, your certifications

This isn’t about trusting a vendor’s security promises. It’s about removing the vendor from the data path entirely.

Evaluating Your Current Risk

Before your next sprint planning, ask your team:

1. Where do our test devices physically live? If the answer is “a third-party data center,” you have third-party risk.

2. What data do our test flows actually contain? Audit your test scripts. You might be surprised what’s accumulated.

3. Can we demonstrate compliance certification coverage for our test environment? If your device lab provider isn’t in scope for relevant certifications, neither is your test environment.

4. What’s our cleanup verification process? “We trust the provider” isn’t an audit-ready answer.

5. Who has access to our test infrastructure? Include vendor employees, contractors, and support staff in your count.

6. What happens if the vendor gets breached? Do you have a notification agreement? A response plan?

The Path Forward

For teams testing sensitive applications, the calculus is changing.

The convenience of cloud device labs comes with hidden costs:

• Compliance gaps that could surface during audits
• Third-party risk in an era where 41%+ of breaches come from vendors
• Data persistence uncertainties that providers acknowledge in their own docs
• Shared infrastructure with unknown security postures

The alternative—controlling your own devices—used to mean massive infrastructure investment. Today, solutions exist that let you:

• Use devices you already own
• Keep all data on your network
• Maintain full compliance scope
• Scale without per-device cloud fees

When your app handles patient health records, payment credentials, or personal financial data, “the provider probably cleans the devices properly” isn’t a security strategy.

Your devices. Your network. Your data never leaves.

That’s not just good security. It’s the only approach that holds up to regulatory scrutiny.

Frequently Asked Questions

Is AWS Device Farm HIPAA compliant?

No. AWS Device Farm explicitly states it is “not in scope of any AWS compliance programs” and that physical mobile device testing data is not encrypted at rest. AWS recommends avoiding entering sensitive information during test sessions. If your healthcare app testing requires HIPAA compliance, you’ll need to use your own devices or find a provider that offers a signed Business Associate Agreement (BAA) with appropriate technical safeguards.

Can test data persist between sessions on cloud device labs?

Yes. AWS Device Farm documentation admits “it is possible for data to persist between sessions in some cases, especially if you make use of the device system outside the context of your app.” Sauce Labs acknowledges that when cleanup encounters issues, devices are set aside for manual inspection—meaning your data could remain on the device until manually reviewed. This creates significant risk for teams testing apps with sensitive user data.

What are the risks of testing fintech apps on cloud device labs?

Fintech apps handle PCI DSS regulated cardholder data. PCI DSS explicitly requires “no cardholder data in non-production environments.” Cloud device labs that can’t guarantee complete data destruction between sessions, don’t encrypt data at rest, and are explicitly excluded from compliance programs create audit risk. With 41.8% of fintech breaches originating from third-party vendors, the infrastructure you use for testing matters.

How do I test healthcare apps without violating HIPAA?

HIPAA requires PHI to be encrypted everywhere, including test environments, and any third-party handling PHI must sign a Business Associate Agreement (BAA). Your options include: (1) using your own devices in a private device cloud where you control encryption and access, (2) using fully synthetic test data that contains no PHI, or (3) ensuring any third-party platform has a signed BAA and meets all HIPAA Security Rule requirements—which AWS Device Farm does not.

What’s the alternative to cloud device labs for sensitive apps?

On-premise or private device clouds give you full control over your devices and data. With peer-to-peer solutions like DeviceLab, your test data never touches third-party servers—it flows directly between your machine and your devices via WebRTC. This architecture eliminates third-party risk, keeps your infrastructure within compliance scope, and ensures you can demonstrate audit-ready controls for sensitive data handling.

Sources: AWS Device Farm Security Documentation, AWS Device Farm Compliance, Sauce Labs Trust Center, IBM Cost of Data Breach Report 2025, SecurityScorecard Fintech Research 2025, HHS Breach Portal, PCI Security Standards Council