Credential Stuffing Incident Response Checklist for Fertility Tracking Apps and Patient Portals

How should teams investigate and scope a credential stuffing incident?

Credential stuffing uses usernames and passwords exposed elsewhere to attempt access to other accounts. Treat a concentrated wave of failed logins—or unusual successful logins—as a potential incident, but distinguish attempted access from verified account access and data exposure.

• Open an incident record. Note when the activity was detected, who is leading the response, which systems may be involved, and the time zone used for all timestamps.
• Preserve authentication logs. Collect failed and successful login events, password resets, MFA challenges, account lockouts, and changes to recovery details. Include available timestamps, account identifiers, IP addresses, device or browser details, and event outcomes.
• Correlate account activity. Compare authentication logs with application audit logs, session creation, API requests, record views, downloads, exports, and changes made after login. Investigate patterns such as repeated attempts across many accounts or a successful login followed by unusual activity.
• Define the incident window and affected population. Record the earliest suspicious activity, the last known related event, affected accounts, and the criteria used to include or exclude accounts.
• Preserve evidence before routine cleanup. Save relevant logs and system records in a controlled location, record who collected them and when, and document any gaps or transformations. Preserve the original evidence where feasible while taking containment steps.
• Document decisions and uncertainty. Separate confirmed facts from hypotheses, and record the basis for conclusions about account access, data access, and the incident’s scope.

For systems that maintain electronic protected health information, HIPAA’s Security Rule includes access-control, authentication, security-incident, and audit-control requirements for regulated entities. See the HHS summary of the HIPAA Security Rule. CISA also recommends logging unsuccessful automated login attempts and alerting security teams to suspicious patterns in its Cybersecurity Performance Goals checklist.

Which fertility apps, patient portals, and connected systems should be examined?

Map the user journey and the data flows behind it. A compromised password may work across systems if users reuse credentials or if accounts share identity services, so examine connected services as well as the app or portal where suspicious logins first appeared.

• User-facing services: fertility or cycle-tracking apps, websites, patient portals, mobile apps, and account recovery or support interfaces.
• Identity and access services: single sign-on, identity providers, MFA services, password-reset tools, session stores, and APIs that issue or validate tokens.
• Clinical connections: electronic health record integrations, provider portals, laboratory or imaging connections, appointment systems, and third-party services that exchange records.
• Data and infrastructure: application databases, cloud storage, analytics platforms, audit and monitoring systems, content delivery networks, and backups containing relevant records or metadata.
• Service providers: vendors that host, support, monitor, or process data for the app or portal. Confirm what records they hold and how quickly they can preserve and provide relevant logs.

For each system, identify its owner, the records it handles, its authentication method, logging coverage, relevant vendors, and the path by which an account could access reproductive health information. Do not assume that every fertility app or connected service is governed by HIPAA: applicability depends on the organization and its role. The FTC explains that its Health Breach Notification Rule may apply to certain health apps and personal health record providers that are not covered by HIPAA; see the FTC Mobile Health App Interactive Tool.

How can teams contain compromised accounts and support account recovery?

Containment should interrupt attacker access while preserving the ability of legitimate users to regain control of their accounts. Prioritize accounts with confirmed unauthorized access, suspicious successful logins, or evidence that an attacker obtained a valid session.

• Block the attack pattern. Apply proportionate rate limits, bot protections, and risk-based controls to suspicious login activity. Avoid controls that unnecessarily prevent patients from accessing timely care or support.
• Secure affected accounts. Require a password change through a verified recovery process when compromise is confirmed or strongly suspected. Check for unauthorized changes to email addresses, phone numbers, recovery methods, or MFA settings.
• Revoke access that may remain active. Use session token revocation to invalidate active sessions and refresh tokens where compromise is confirmed or reasonably suspected. Revoke or rotate related credentials and tokens if evidence indicates they may also be exposed.
• Strengthen authentication. Require or offer MFA where appropriate, especially for accounts showing suspicious activity. CISA explains that MFA can help prevent account takeover even when an attacker has a user’s password in its identity and access management guidance.
• Provide a safe recovery route. Give affected people a clear way to reset credentials, report suspicious activity, and get help if they cannot access their account. Verify identity using an established process, and do not ask users to send passwords or one-time codes to support staff.
• Communicate discreetly. Use neutral subject lines and wording that does not unnecessarily reveal fertility tracking, treatment, or patient-portal use on a shared device or email account.

Record when access controls were changed, which accounts or tokens were affected, who approved the action, and whether users experienced disruption. If an account may be used for time-sensitive clinical communication, coordinate containment with the appropriate care or support team.

How should teams assess exposure of reproductive health information?

Determine what the attacker could reach and what the available evidence shows they actually viewed, acquired, changed, or shared. A successful login alone does not establish which records were accessed, while missing or incomplete logs can limit the certainty of any conclusion.

• Identify the information associated with affected accounts. Depending on the service, this may include cycle dates, ovulation estimates, pregnancy or fertility information, treatment details, test results, messages, appointment information, account identifiers, and connected-device or EHR data.
• Review actions after suspicious authentication. Look for record views, searches, downloads, exports, messages, profile changes, API calls, and access to connected systems. Match events to accounts and the incident window where possible.
• Assess the information and circumstances. Document the sensitivity and amount of information involved, whether it could identify an individual, who may have accessed it, whether it appears to have been acquired or viewed, and what steps reduced further risk.
• Separate findings by confidence. State what is confirmed, what is inferred from available logs, and what cannot be established. Avoid describing data as “not accessed” solely because no access event appears in logs that are incomplete.

For HIPAA-regulated entities, an impermissible use or disclosure of unsecured protected health information is generally presumed to be a breach unless the entity demonstrates a low probability that the information was compromised through the required assessment. HHS identifies the nature and extent of the information, the recipient, whether it was actually acquired or viewed, and mitigation as factors in that assessment. See the HHS Breach Notification Rule guidance. Other requirements may apply to consumer health apps; qualified counsel should assess the organization’s role, data, and applicable laws.

What should affected-person notices include?

First determine which notification rules apply. HIPAA’s Breach Notification Rule applies to covered entities and business associates in specified circumstances; the FTC’s Health Breach Notification Rule may apply to certain personal health record vendors and related entities outside HIPAA. State law, contracts, and other requirements may also affect the analysis, recipients, and deadlines.

When HIPAA notification is required, HHS says individual notice must be provided without unreasonable delay and no later than 60 days after discovery of the breach. The notice should include, to the extent possible, a brief description of what happened, the types of information involved, steps individuals can take to protect themselves, the organization’s investigation and mitigation efforts, and contact information. Review the HHS requirements for breach notices and obtain legal advice on the facts and applicable deadlines.

For a notice under the FTC Health Breach Notification Rule, review the rule’s separate requirements rather than assuming HIPAA’s process applies. The FTC’s business guidance on complying with the Health Breach Notification Rule describes notice content and delivery considerations for covered organizations.

As a practical matter, make notices understandable and specific without overstating what the investigation has established. Explain what happened and when, what categories of information may be involved, what the organization has done, what recipients can do, and how to ask questions or get account assistance. Describe uncertainty plainly, and provide a private support channel for questions about reproductive health information.

How should security, privacy, legal, clinical, and communications teams coordinate?

Use one incident lead and a shared, access-controlled record of decisions so investigation, containment, care, and notification work remain aligned. Limit access to sensitive incident details to people who need them for their role.

• Security and engineering investigate authentication logs, application audit logs, technical access, attack patterns, containment, and evidence preservation.
• Privacy and legal assess the organization’s obligations, the information involved, relevant contracts and laws, and whether notices or regulator reports are required. Legal review should not delay urgent containment or evidence preservation.
• Clinical and patient-support teams identify potential effects on care, provide safe account-recovery support, and flag urgent patient needs through established channels.
• Communications prepare consistent, plain-language messages and support guidance, coordinate timing with legal and privacy teams, and avoid claims that exceed verified findings.
• Vendors and partners preserve relevant records, explain system capabilities and log limitations, and follow the incident and notification responsibilities in applicable agreements.

Keep a dated decision log that records the evidence reviewed, the people involved, the decision made, and the reason. For notification decisions, record the rule or legal analysis applied, the affected population estimate, known uncertainties, and any follow-up needed as new evidence becomes available.

What evidence gaps and incident limitations should teams document?

Document limitations explicitly so later reviewers can understand what the investigation could—and could not—establish. A clear record of evidence gaps supports defensible decisions and helps teams prioritize improvements.

• Logging limitations: systems with missing, incomplete, delayed, or inconsistent authentication logs or application audit logs; unavailable third-party records; and gaps in timestamps or time-zone information.
• Identity uncertainty: shared devices, VPNs, proxy services, changing IP addresses, or other conditions that prevent reliable identification of the person behind an event.
• Access uncertainty: records that were available to a signed-in account but have no reliable event-level view or download tracking, or systems that do not record actions consistently.
• Scope uncertainty: accounts or integrations that could not be assessed, uncertain incident start or end times, and estimates that may change as vendors provide information.
• Evidence-handling limits: records altered by routine retention or system operations, delayed collection, unavailable originals, or other breaks in the documented preservation process.

For each gap, note its effect on account and data scope, the steps taken to address it, who owns follow-up, and whether it changes the confidence of the exposure assessment. In summary, preserve evidence, distinguish attempted access from confirmed activity, contain compromised accounts, assess reproductive health information carefully, and have the right teams determine applicable notices and next steps.

FAQs

When should an account be treated as compromised after a credential stuffing attack?

Treat an account as confirmed compromised when evidence shows an unauthorized successful login, attacker-controlled changes, or other unauthorized activity. If the evidence is incomplete but suspicious successful access or credible signs of valid credentials exist, treat the account as potentially compromised for containment while documenting the uncertainty. Failed login attempts alone show attempted access, not necessarily account compromise.

How can teams determine which fertility records were accessed?

Correlate authentication logs with application audit logs, record-view and export events, API activity, messages, and relevant EHR integration logs. Define the affected accounts and time window, then distinguish confirmed views or downloads from information merely available to an account. If event-level logging is missing, document what cannot be determined rather than concluding that no records were accessed.

Should active sessions and tokens be revoked during containment?

Yes, revoke active sessions and tokens for accounts with confirmed or reasonably suspected compromise when doing so is appropriate to the incident. Consider refresh tokens and connected services as well as browser or app sessions, and document the scope and timing of revocation. Coordinate with support or clinical teams if access disruption could affect a user’s care.

Who should assess breach notification requirements?

Privacy and legal teams, with qualified counsel as needed, should assess applicable requirements using the incident facts provided by security, engineering, and relevant vendors. The analysis should consider whether HIPAA, the FTC Health Breach Notification Rule, state law, contracts, or other obligations apply; do not assume every fertility app is covered by the same rules.