What happens when an unused SaaS app still has access to patient data?

An unused app can become a live exposure point if its tokens, credentials, or permissions were never removed. If that app is breached, patient data may be exposed even though no one has logged in recently. HIPAA’s newer expectations make this especially important, because dormant software is not harmless if it still has standing access.

Why an Unused App Can Still Expose Patient Data

An app that is no longer actively used can still retain the ability to read, copy, sync, or export patient records if its API token, service credential, or delegated permission was never revoked. That turns “unused” into a misleading label: the software may be dormant from a business perspective while remaining fully live from an access-control perspective. In healthcare, that matters because patient data exposure can occur without any current user activity, only a standing trust relationship that was forgotten.

The practical failure is not usually that the app is performing something unusual; it is that nobody removed its access when the app fell out of use. Current guidance suggests treating dormant integrations as part of the data-access surface until they are explicitly inventoried, reviewed, and offboarded. The Ultimate Guide to NHIs is useful here because it frames the problem as lifecycle control, not just login hygiene. In practice, many teams discover the exposure only after a vendor, workflow, or internal owner has already changed and the old access path was never cleaned up.

How the Access Path Remains Live in Practice

Most SaaS integrations do not depend on a person sitting at a keyboard. They rely on machine credentials, OAuth grants, API keys, service accounts, or embedded secrets that continue to work until they are rotated or revoked. If a stale app still has patient-data scopes, it may continue to query records, receive webhooks, or pull exports even after the business no longer uses it. That is why unused does not mean harmless.

The important distinction is between application usage and authorization state. An app can be “inactive” in the help desk sense but still fully authorized in the identity and secrets layer. That creates a hidden dependency: the app’s access survives changes in staffing, procurement, and workflow ownership unless someone explicitly closes the loop. The best practice is evolving toward inventory-driven offboarding, where teams verify what the integration can reach, who owns it, what data it can touch, and whether the credential can still authenticate. The OWASP Non-Human Identity Top 10 is relevant because this is fundamentally a non-human identity lifecycle problem, not just an app-support issue.

Stale tokens can continue to authorize API calls long after the app has been forgotten.
Broad OAuth scopes can expose more patient data than the original workflow ever needed.
Unused integrations often bypass normal user review because no one thinks to audit them.
Shared or copied secrets make revocation harder because the true access footprint is unclear.

For patient-data systems, the control question is not “Is anyone using the app?” but “Can it still authenticate and reach regulated data?” That distinction matters because access persistence, not activity, is what creates the exposure. These controls tend to break down when integrations are owned by a departed team, copied across environments, or left outside the normal access-review process.

Common Failure Patterns and What Changes at Scale

Tighter integration control often increases operational overhead, requiring organisations to balance convenience against the need for explicit offboarding. One common edge case is a retired app that still receives data through a shared service account or delegated connector, which makes the exposure harder to spot than a simple abandoned login. Another is vendor-managed software where the internal team assumes the vendor will disable access, while the vendor assumes the customer already did.

Healthcare environments also amplify the issue because one stale permission can cover large patient populations, replicated exports, or downstream analytics tools. There is no universal standard for exactly how often every SaaS grant must be reviewed, but current guidance favors short-lived credentials, explicit ownership, and periodic confirmation that the integration still has a business need. NHIMG research notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a strong signal that unused access is often left in place far too long. That gap is especially relevant when patient records are involved.

If the app can still reach protected systems, treat it as active until proven otherwise. In practice, the risk increases fastest when the app is old, poorly documented, cross-functional, or tied to a data export path that no one is actively watching.

Risk and Threat Considerations

Unused SaaS access creates a standing exposure because the security boundary is controlled by credential validity, not by current business use. That means patient data can remain reachable through a forgotten integration, even when operational ownership has disappeared.

Failure mechanism: A revoked workflow is not the same as revoked authorization. If tokens, OAuth grants, API keys, or service-account credentials remain valid, an attacker who obtains that access path can query, export, or pivot through patient data without needing a fresh user login.

Impact: The result can be unauthorized disclosure of protected health information, broader blast radius than expected, and delayed detection because dormant integrations are rarely monitored as closely as active ones.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI Lifecycle Management — Lifecycle Management	Unused SaaS access is a dormant non-human identity lifecycle failure.
	Secrets and Credential Management — Secrets and Credential Management	Patient-data exposure persists if tokens or API keys remain valid.
	Authorization and Least Privilege — Authorization and Least Privilege	Stale SaaS grants often retain broader access than the app still needs.
Recommendation — Inventory, offboard, and revoke dormant app credentials before treating the integration as retired. Rotate and revoke the app's secrets to remove standing access to regulated data. Reduce scopes to the minimum data set and remove unused delegated permissions.
CIS Controls v8	5 — Account Management	Unused SaaS apps should be removed from active account and access inventory.
	6 — Access Control Management	Standing access to patient data must be revoked when business use ends.
Recommendation — Disable or delete inactive application accounts and review their access regularly. Enforce least privilege and remove expired access paths to patient data.
NIST CSF 2.0	PR.AA-01 — Identity and Access Management	The issue is a live access relationship that outlasted its business purpose.
	PR.DS-01 — Data-at-Rest Protection	Patient data exposure becomes material when dormant access can still reach records.
Recommendation — Maintain an accurate access inventory and remove stale authorisations promptly. Restrict which applications can reach sensitive data and verify those boundaries continuously.

Practitioner Guidance

What to prioritise: Inventory every SaaS app that can touch patient data and separate “not in use” from “no longer authorised.” If the app still holds a credential, scope, or delegated grant, treat it as an active exposure until it is explicitly removed.

What to verify: Confirm the actual data path, not just the business owner’s intent. Verify whether the app can still read records, receive exports, or access downstream systems, and check whether the credential is unique to that app or shared elsewhere.

Decision rule: If an integration can authenticate to patient-data systems, rotate or revoke its access before relying on usage reports or inactivity as evidence of safety. Dormancy is not a control.

Practitioner takeaway: The core judgement is that access lifecycle matters more than application activity; a forgotten SaaS app is still a live confidentiality risk until its authorisation is removed.