How to Respond to a Shared Password Breach: Records, Authorization, and Incident Response

A shared password breach can expose an account, its data, and any systems or records the account can reach. Treat the incident as a potential security event even before you know whether someone used the password without permission. Contain access, preserve evidence, establish what happened, and coordinate a response that fits your organization’s policies and legal obligations.

Contain Exposed Credentials and Revoke Access

Change the exposed password promptly, and stop distributing or reusing it. If the account is shared across people or systems, identify every place the credential was used and replace it there too. Use unique credentials for each account so one exposure does not create several paths into your environment.

Credential revocation should include more than changing a password. Invalidate active sessions and session tokens where possible, remove remembered devices or app passwords, and revoke related API keys or other credentials that may have been exposed. If you cannot confirm that access has ended, temporarily disable the affected account while you investigate.

Use a secure process to issue replacement credentials to authorized users. Avoid sending passwords through the same channel that exposed them, and do not record the new secret in incident notes or evidence files.

Review Accounts and Access Logs

Identify the affected account, its owners and users, and the systems it can access. Review group memberships, delegated permissions, connected applications, and any elevated roles. A privileged access review can help determine whether the account had access beyond what its users needed.

Examine authentication and activity logs for unusual sign-ins, failed attempts, new devices, unfamiliar locations, changes to account settings, and access outside normal patterns. Compare events with the known users’ schedules and authorized activity, while accounting for legitimate explanations such as travel or approved maintenance.

Logs can indicate that a record was viewed, downloaded, or changed, but they may not prove that a person copied, retained, or shared it. Check available file, database, application, and network records for corroborating activity, and document gaps in logging or retention.

Preserve Records and Incident Evidence

Preserve relevant authentication and activity data before routine retention or system changes remove it. Authentication log preservation may include sign-in events, session records, access histories, administrative actions, alerts, and logs from connected services. Record the time range and systems covered, along with any known gaps.

Keep original evidence intact when possible, restrict access to it, and document who collected, transferred, or reviewed each item. A clear chain of custody helps show how evidence was handled. Record collection times, time zones, tools used, file locations, and any transformations or copies made.

Preserve incident-related communications, account and permission snapshots, relevant policies, and a timeline of response decisions. Do not delete messages or alter logs to make them easier to review. If forensic work may be needed, coordinate collection with qualified personnel before making changes that could overwrite evidence.

Assess Authorization and Data Impact

Determine who knew or used the password and what access each person was permitted to have. A shared credential can make attribution difficult: a successful sign-in may identify the account without identifying the individual behind it. Treat the event as an unauthorized access assessment, not as proof of misuse solely because a password was exposed.

Compare observed activity with approved duties, access permissions, and the account’s normal behavior. Identify whether access went beyond authorization, whether data was viewed or altered, and whether records may have been downloaded or disclosed. Consider the sensitivity of affected information, the number of people or records involved, and whether other accounts or systems were reachable.

Document what is confirmed, what remains uncertain, and what evidence supports each conclusion. Avoid treating the absence of a log entry as proof that an action did not occur if monitoring was incomplete.

Coordinate the Incident Response

Assign an incident lead and involve the teams needed to contain and assess the event, such as security, IT, system owners, privacy, legal, and communications. Follow your organization’s incident response plan, including any escalation requirements or decision-making authority.

Keep a dated record of key actions, findings, decisions, and open questions. Share incident details only with people who need them to respond, and use approved secure channels. Coordinate technical changes so that containment does not unintentionally destroy evidence or disrupt essential services without a plan.

If the incident may involve criminal activity, regulated information, or a significant operational impact, seek appropriate legal, forensic, or law-enforcement guidance through established organizational channels. Keep response actions proportionate to the evidence and the potential harm.

Recover Access and Prevent Recurrence

Restore access only after exposed credentials and associated sessions have been revoked, affected systems have been reviewed, and the account’s authorized users and permissions are understood. Confirm that replacement credentials work for legitimate users and that access is limited to what each person needs.

Where practical, replace shared accounts with individual accounts so actions can be attributed and access can be removed person by person. Require multifactor authentication for important systems, use a secure password manager or other approved credential-sharing method when shared access is unavoidable, and set a process for rotating credentials when users or responsibilities change.

Review whether monitoring and retention settings provide enough visibility for future investigations. Train users not to reuse passwords or share secrets through unapproved channels, and test the revised access and incident procedures so teams know how to act if credentials are exposed again.

Evaluate Notification Obligations

Assess breach notification obligations based on the type of information involved, the people affected, where they are located, the applicable contracts and policies, and the findings of the investigation. Requirements and deadlines can vary, so involve qualified legal or privacy personnel promptly rather than assuming that every exposed password triggers the same notification process.

Document the basis for decisions about whether notice is required, who must receive it, what it should say, and when it must be sent. If notification is required, coordinate accurate, timely communications with relevant internal teams and follow applicable procedures. Keep records of the assessment and any notices provided.

Throughout the response, distinguish confirmed facts from uncertainty, preserve evidence, and make decisions that reflect the scope and impact you have established.

FAQs

What credentials and tokens should be reset after a shared password breach?

Change the exposed password everywhere it was used, then invalidate active sessions and session tokens associated with the affected account. Review and revoke related API keys, app passwords, recovery methods, and connected application credentials if they may also have been exposed. Reset only what is relevant to the incident, and verify that the old access no longer works.

How can access logs show whether records were accessed or copied?

Authentication logs can show sign-ins and session activity, while application, file, database, and network logs may show records viewed, changed, or downloaded. Compare timestamps, account activity, and available device or transfer records to build a clearer picture. Logs may not establish who used a shared account or prove that information was copied or retained, so document limitations and corroborate findings where possible.

What records should be preserved during incident response?

Preserve relevant authentication and activity logs, account and permission details, alerts, system snapshots where appropriate, incident communications, and a timeline of actions and decisions. Record when and how each item was collected, where it is stored, who has handled it, and whether it was copied or changed. These steps support a reliable chain of custody.

When may a shared password breach require notifying affected parties?

Notification may be required when the investigation finds that particular information was accessed, acquired, or disclosed under applicable law, regulation, contract, or organizational policy. The answer depends on the information involved, the affected people and locations, and the facts established during the response. Consult qualified legal or privacy personnel to assess the relevant requirements and deadlines.