ChatGPT Security History Guide: Review Sign-Ins, MFA and Passkey Changes, Manage Sessions, Rotate API Keys, and Respond to Compromise

What changed on September 25: Security History gives ChatGPT users a review surface for account activity

OpenAI’s September 25, 2026 ChatGPT release notes introduced Security History, a web-based account-security view that can show recent security-relevant activity for a user’s account. According to OpenAI, users can reach it on the web by navigating to Settings > Security and login > Security history. This matters because account security work is easiest when users can inspect concrete events rather than rely only on memory, email notifications, or billing surprises.

OpenAI describes Security History as a place where users can review events such as recent sign-ins, sign-outs, password changes, changes to multi-factor authentication, passkey changes, and other security-setting changes. The release note also says those events can include time, location, and device details. That combination gives individuals, families, school administrators, startup founders, enterprise workspace owners, legal teams, and API users a practical starting point for answering a narrow but important question: “Does this account activity look consistent with how we actually use ChatGPT and OpenAI services?”

The word “starting point” is important. OpenAI notes that some details may be approximate or unavailable, so Security History should not be treated as an exact forensic record, a guaranteed compromise detector, or a complete reconstruction of every action ever taken with an account. A location may reflect network routing, mobile carrier behavior, VPN use, corporate egress, or an approximate mapping rather than a precise physical address. A device description may be partial, generic, or absent. A missing detail is a reason to investigate calmly, not a reason to assume either safety or compromise.

For a practical review, the goal is not to prove a security conclusion from one clue. The goal is to assemble a reasonable picture from multiple signals: whether the time matches the user’s activity, whether the device family is expected, whether the approximate location fits the user’s network patterns, whether the event type is normal for the account, whether MFA or passkey changes were planned, whether API usage changed unexpectedly, and whether anyone with legitimate access recently changed browsers, phones, devices, passwords, identity-provider settings, or workspace policies.

Security History also changes the operational rhythm for advanced users. A developer who uses ChatGPT, Codex, and API keys can combine Security History review with key rotation and usage inspection. A founder can make account checks part of the offboarding checklist when a contractor leaves. A school or family can use it to discuss sign-in hygiene without collecting more personal information than necessary. An enterprise administrator can ask users to preserve relevant event details before support escalation, while still avoiding the unsafe practice of sharing passwords, session cookies, tokens, or full private logs in chat channels.

The article explains OpenAI Advanced Account Security for ChatGPT and Codex, including passkey and physical security key authentication that replaces passwords. The OpenAI Advanced Account Security: How Passkeys Replace Passwords for ChatGPT and Codex article is a focused companion for Passkeys and MFA Setup because this is the most exact match for a section about setting up phishing-resistant sign-in protections such as passkeys and MFA-related account hardening.

How to open Security History on the web

OpenAI’s documented path is direct: on the web, go to Settings > Security and login > Security history. Because interface wording, rollout timing, plan access, region, app version, and workspace policies can vary, the safest instruction for teams is to cite the documented path and avoid building internal procedures that depend on undocumented buttons, screenshots, or assumed mobile-app parity. If a user cannot see the feature, the next step is to verify that they are using the web interface and to check whether the account, workspace, or rollout state differs from the documented release note.

1. Open ChatGPT on the web using your normal account. Do not sign in through a shared browser profile if you are investigating account activity, because shared profiles can make it harder to distinguish your own sessions from someone else’s.
2. Open Settings. Use the account’s settings area rather than relying on browser history, email search, or memory of prior notifications.
3. Go to Security and login. This is the security-focused section identified by OpenAI’s release note.
4. Open Security history. Review the visible events, including event type, time, device details, and location details where available.
5. Record only the minimum useful information if escalation is needed. Preserve event times, event types, and high-level device or location details, but do not copy passwords, passkeys, recovery material, session tokens, private API keys, or sensitive conversation content into tickets, spreadsheets, or chat messages.

A good first review takes less time when the user prepares context before opening the page. Ask whether they recently changed phones, installed a new browser, used a VPN, traveled, reset a password, enrolled MFA, removed a passkey, signed in from a work machine, used a family device, accepted an identity-provider prompt, or gave a contractor temporary access to a shared operational account. These events can create legitimate entries that look unfamiliar when viewed without context.

For organizations, the review path should be written into an account-security runbook in plain language. The runbook should say who performs the review, when it is required, what evidence may be preserved, what must never be copied, when API keys must be rotated, when all sessions must be logged out, and who is authorized to contact OpenAI Support. That prevents a stressful account concern from turning into ad hoc behavior such as pasting secrets into a team chat or deleting evidence before anyone records the basic event timeline.

What event types Security History can show

OpenAI states that Security History can show recent sign-ins, sign-outs, password changes, changes to MFA, passkey changes, and other security-setting changes. These categories are useful because they map to common account-risk questions. A sign-in asks whether someone accessed the account. A sign-out can indicate normal session cleanup or response activity. A password change asks whether account credentials were modified. MFA and passkey changes deserve special attention because they affect future account access, not just past access.

For knowledge workers, the most common benign surprises are new devices, browser resets, VPNs, travel, and work-from-home network changes. For developers and founders, surprises often come from operational habits: using a personal account on a test machine, signing into a browser inside a remote desktop, switching between password-manager profiles, or having an old laptop wake and refresh sessions. For administrators, the risk is not that every unfamiliar event is malicious; the risk is that unclear events get ignored because nobody owns the follow-up.

For legal-technology professionals, security-history review should be handled with special restraint. Do not paste client names, matter details, privileged document titles, protected health information, personal identifiers, or confidential case facts into a general incident discussion unless the organization’s authorized process requires it and the channel is approved. Security History can help identify account events, but it is not a substitute for a firm’s professional-responsibility analysis, confidentiality controls, preservation obligations, or qualified legal advice.

For educators and parents, the same principle applies in a youth-safety context. If a child, student, or family member reports unfamiliar account activity, avoid public blame or invasive questioning. Review the event categories, identify whether shared devices or school networks explain the activity, change exposed or reused passwords where appropriate, and involve the platform’s support path or qualified local support when safety, coercion, harassment, or account misuse is suspected.

How to interpret time, location, and device details without overclaiming

Security History can include time, location, and device details, but OpenAI’s release note cautions that some details may be approximate or unavailable. A disciplined review treats those fields as indicators, not as courtroom-grade proof. Time can be affected by time zones, delayed memory, shared calendars, late-night usage, and automated sign-in refreshes. Location can be affected by IP address mapping, VPNs, corporate networks, mobile carriers, travel, and cloud-based routing. Device details can be affected by generic browser strings, app changes, operating-system updates, and privacy features.

A location that differs from a user’s physical city is not automatically evidence of compromise. For example, a corporate network may route traffic through a regional gateway; a mobile carrier may show a nearby metropolitan area; a VPN may show the location of an exit node; and some network mappings can be imprecise. The right question is narrower: “Is this location consistent with any network path the user intentionally used around that time?” If the user was not using a VPN, was not traveling, and cannot connect the event to a known network, the event deserves escalation in context with other signals.

A device value can also be ambiguous. A browser update may change how a device is represented. A user may sign in from an embedded browser, a company-managed laptop, a tablet, or a remote desktop environment. A device label that is generic or missing does not prove that the account is safe or compromised. It means reviewers should look for corroboration: Was there a password change? Was MFA changed? Were passkeys changed? Was there unexpected API usage? Did the user receive security notifications? Did a shared machine or contractor device have legitimate access?

Time should be checked against local reality rather than assumed from memory alone. Ask the user to compare the event time against calendar entries, travel records, known work sessions, browser history on their own device, password-manager activity, and organization sign-in logs where authorized. Do not request personal browsing history, private messages, medical information, or unrelated location records unless your organization has a lawful, necessary, and approved process. The account-security question is usually answerable with minimal data.

Operational rule: Treat Security History fields as triage evidence. A single unfamiliar city, device label, or timestamp should prompt careful review, not an immediate public accusation or a claim that compromise is confirmed.

Normal versus suspicious: a review table for Security History events

The following table is a recommended review aid, not an OpenAI compromise classifier. It deliberately avoids treating one clue as proof. Use it to decide whether an event is likely explainable, needs user confirmation, or requires immediate account-protection steps such as changing an exposed password, logging out all sessions, deleting affected API keys, inspecting usage, preserving useful evidence, and contacting OpenAI Support as OpenAI recommends for unrecognized activity.

In practice, suspiciousness rises when independent clues point in the same direction. An unfamiliar approximate location is one clue. An unfamiliar location plus an unrecognized device plus an MFA change is a stronger concern. An unexplained passkey change plus unexpected API usage is stronger still. Conversely, a new laptop, a planned password-manager migration, a known VPN, and an expected passkey enrollment may explain a cluster of events. The reviewer’s job is to connect the event record with authorized user context, not to declare certainty from a single row.

Teams should also distinguish between account compromise and policy drift. A shared founder account, a contractor using a personal machine, or a team member signing in from an unmanaged browser may be authorized but still unsafe. Security History can expose those patterns, but the fix may be governance: individual accounts, stronger MFA, passkeys, least-privilege API keys, offboarding procedures, and written approval rules for who may access production-connected OpenAI resources.

The article covers the ChatGPT Privacy Center, including memory, personalized ads, Temporary Chat, connected apps, model improvement, data export, and account security settings. The ChatGPT Privacy Center Guide: Memory, Personalized Ads, Temporary Chat, Connected Apps, Model Improvement, Data Export, and Account Security article is a focused companion for ChatGPT Privacy Settings because a security-history guide that tells users what to review after account activity naturally benefits from a direct link to the broader privacy and account-control settings users may need to audit.

Why Security History is not a complete incident-response system

Security History is valuable because it gives users a place to review recent account-security events. It is not, based on OpenAI’s documented description, a guarantee of complete forensic coverage, exact geolocation, automatic attack attribution, or recovery. Treating it as a full incident-response platform would create false confidence and could cause teams to miss evidence outside the account view, such as compromised email, reused passwords on other services, exposed API keys in source code, unsafe browser extensions, malware on a device, or unauthorized access through a separate identity provider.

A complete security review often crosses boundaries that Security History does not claim to cover. If a password was reused, the exposure may have occurred on another website. If an API key was copied into a repository, the key risk exists even if ChatGPT web sign-ins look normal. If a passkey was added on a stolen device, the device-management question may sit outside ChatGPT. If a school or company uses managed accounts, additional identity-provider logs may be relevant, but access to those logs should follow the organization’s approved process and privacy rules.

OpenAI’s account-security guidance for unrecognized activity emphasizes concrete defensive steps: change an exposed, reused, or shared password; log out of all sessions; delete affected API keys and review API usage; preserve relevant Security History details; and contact OpenAI Support. Those steps are practical because they reduce future access, invalidate risky credentials, create an evidence trail, and move the issue into the official support channel. They do not guarantee recovery or prove root cause, and they should not be described that way in internal reports.

For regulated or high-stakes environments, Security History should feed into an existing incident process rather than replace it. A healthcare vendor, law firm, school district, financial-services team, or enterprise software company may need separate escalation paths for privacy, legal, contractual, customer, insurance, and regulatory analysis. This guide can support account-security triage, but it is not legal advice, breach notification advice, compliance certification, or a substitute for qualified incident-response counsel and security professionals.

A conservative review workflow for the first 15 minutes

The first 15 minutes after noticing unfamiliar activity should be calm, narrow, and evidence-preserving. Panic creates avoidable mistakes: deleting all events without recording timestamps, rotating the wrong key while leaving the exposed one active, sharing screenshots with sensitive account information in a public channel, or accusing a user before checking VPN and travel context. The workflow below is a recommended operational pattern built around OpenAI’s documented security guidance and the limitations of approximate or unavailable details.

1. Use a trusted device and network. If the current device may be compromised, move to a managed or otherwise trusted device before changing account credentials. Do not type passwords or recovery information into a device you suspect is infected or controlled by someone else.
2. Open Security History using the documented web path. Navigate to Settings > Security and login > Security history and identify the event types, times, and available device or location details.
3. Build a short timeline. Record the minimum useful facts: event type, timestamp, broad device description, broad approximate location if shown, and whether the user recognizes the event. Avoid storing secrets, tokens, full API keys, private content, or unnecessary personal information.
4. Ask context questions before concluding. Check for travel, VPN use, new devices, browser resets, password-manager changes, phone replacement, work-network routing, family-device use, contractor access, and planned security updates.
5. If activity remains unrecognized, follow OpenAI’s defensive sequence. Change an exposed, reused, or shared password; log out of all sessions; delete affected API keys and review API usage; preserve useful details; and contact OpenAI Support.
6. Escalate internally when the account touches sensitive work. If the account is connected to customer data, legal work, student data, production systems, payment workflows, or source code, involve the authorized security, legal, privacy, or administrative owner before making external statements or destructive changes.

This workflow intentionally separates observation from response. Observation asks what the Security History page shows and what the user can explain. Response begins when events remain unrecognized, when sensitive access methods changed, when API usage appears abnormal, or when the account has access to consequential systems. Keeping those phases separate reduces the chance of both underreacting and overreacting.

Human approval remains mandatory for consequential follow-up. Do not let an AI assistant send incident notifications, contact customers, submit legal notices, change billing settings, delete production data, revoke broad enterprise permissions, publish a public statement, or file reports without an authorized human decision-maker. AI can help draft a checklist, organize a timeline, or propose questions, but accountable people must approve external communications and irreversible actions.

What “unrecognized activity” should mean in a practical account review

“Unrecognized” should not mean “the user did not instantly remember it.” It should mean that, after a reasonable check, the activity does not match known devices, known networks, known users, planned security changes, or expected usage. A user may forget a late-night sign-in after travel, or an administrator may forget a password reset. Conversely, a user may assume an event is normal because the city looks nearby, while the surrounding MFA or passkey change is actually the more important signal.

A useful decision rule is to classify each event into one of four temporary states: recognized, plausibly explained, unresolved, or unrecognized and concerning. Recognized events match a specific user action. Plausibly explained events match a likely network or device explanation but may need confirmation. Unresolved events need more context but do not yet justify a conclusion. Unrecognized and concerning events affect access control, appear in suspicious clusters, or remain unexplained after checking normal causes.

This classification also helps managers avoid a common error: asking a user to “prove” that an event was not them. Security reviews should be evidence-led and respectful. Ask focused questions, avoid unnecessary personal details, and document uncertainty. If the account is part of a company, school, or professional practice, follow the organization’s access, privacy, HR, and legal processes rather than inventing a disciplinary process from Security History alone.

Where API keys fit into the opening review

Security History focuses on account-security events, but many advanced OpenAI users also operate API keys. OpenAI’s account-security guidance specifically tells users who see suspicious activity to delete affected API keys and review API usage. That is because API keys can allow programmatic usage independent of a visible ChatGPT web session, and a key exposed in a repository, log, screenshot, notebook, build system, or shared document can remain risky until revoked.

The practical implication is simple: if account activity is unrecognized and the account has API keys, web-session cleanup is not enough. Review the API-key area and usage records through the official OpenAI platform surfaces available to your account, identify keys that may be affected, delete affected keys, and replace them only through a controlled rotation process. Do not paste full keys into support chats, AI prompts, ticket titles, screenshots, or incident timelines. Store only key names, creation context, last-known application owner, and the fact that a key was revoked or replaced.

For founders and developers, the minimum key-rotation question is: “Which applications, scripts, notebooks, plugins, development machines, CI jobs, or vendors could have used this key?” If the answer is unclear, the organization has a key-inventory problem as well as a possible compromise concern. Label keys by application and owner where the platform supports it, keep keys out of source code, rotate keys when staff leave or repositories are exposed, and ensure that revocation does not break production without an authorized rollback or deployment owner present.

For enterprise administrators, API-key response should be coordinated. A well-meaning engineer may revoke a production key at the first sign of concern, causing service disruption without eliminating the root risk. A cautious team may delay too long because nobody knows who owns the key. The safer pattern is to preserve the timeline, identify affected keys, prepare replacements where needed, revoke affected keys, review usage, and document the change under the organization’s incident and change-management process.

The opening principle: reduce future access before debating root cause

The first phase of account-security response should prioritize reducing future unauthorized access. Root-cause analysis is important, but it should not delay basic containment when activity remains unrecognized. OpenAI’s documented guidance points users toward changing exposed, reused, or shared passwords; logging out all sessions; deleting affected API keys; reviewing API usage; preserving relevant details; and contacting Support. Those actions are concrete, reversible or manageable in many environments, and focused on reducing ongoing risk.

At the same time, response should be proportionate. Do not wipe devices, delete conversations, accuse staff, publish breach notices, revoke unrelated enterprise permissions, or make legal commitments solely because a location field looks odd. Approximate or unavailable details mean that Security History must be interpreted alongside user context and other authorized logs. The right posture is neither complacency nor alarmism: preserve useful evidence, secure access paths, inspect usage, and escalate through approved channels.

This guide will build from that principle. The next stages of a disciplined review are session management, password and MFA hardening, passkey review, API-key rotation, evidence preservation, support escalation, and periodic account checks. Each step should be performed with the same conservative assumptions established here: do not expose secrets, do not overclaim what Security History proves, do not bypass workspace or provider permissions, and do not let automation take consequential actions without human approval.

Review and triage Security History without turning approximate clues into false certainty

OpenAI’s Security History feature, introduced in the September 25 release notes, gives ChatGPT users a recent account-activity surface for events such as sign-ins, sign-outs, password changes, MFA changes, passkey changes, and other security-setting changes. Treat that surface as a structured review aid, not as a complete forensic record or a guaranteed compromise detector. The practical goal in this section is to convert visible event details—time, approximate location, device, and event type—into a disciplined triage decision: expected, explainable, suspicious, or urgent.

The most common mistake in account reviews is overfitting one field. A city that looks wrong may reflect mobile routing, VPN use, corporate egress, travel, or approximate location data. A device label that looks vague may still belong to a legitimate browser profile. A familiar time may still be risky if it coincides with an MFA or passkey change the account owner did not authorize. Review the event as a bundle of evidence, then record what is known, what is inferred, and what remains unresolved.

OpenAI states that some Security History details may be approximate or unavailable. That limitation matters operationally: your response should not depend on proving an exact physical location or building a courtroom-grade device attribution. Instead, decide whether the activity is consistent with the account owner’s real behavior and whether the event type created new persistence, such as a password change, MFA change, passkey change, active session, or API key exposure.

Start with a clean review window and a known time standard

Before judging any event, choose a time standard for the review. For individuals, use the account owner’s local time zone and write down the UTC offset if known. For companies, security teams should use the organization’s incident time standard, commonly UTC, and separately record the affected user’s local time. This prevents a normal late-night sign-in from being misclassified because one reviewer reads the timestamp in local browser time while another converts it mentally to UTC.

Use a simple conversion note at the top of the review record. For example: “Security History viewed on 2026-09-26 from New York; reviewer is interpreting displayed times as shown in the web interface and converting notable events to UTC in the evidence log.” If the interface does not make the time zone obvious to the reviewer, record that uncertainty rather than silently assuming. The review remains useful when uncertainty is explicit.

For remote teams, use calendar data only as corroboration and only when the account owner or the organization has authorized that review. A sign-in around a meeting, travel day, or device replacement may be explainable, but private calendars, HR records, and travel systems can contain sensitive personal information. Security triage should use minimum necessary evidence and should not become a broad surveillance exercise.

Recommended review header

Account reviewed:
Reviewer:
Review start time:
Displayed time basis:
UTC conversion method:
Account owner's usual time zone:
Known travel/VPN/corporate network context:
Scope limits:
Immediate risk decision:

Read the event stream in clusters, not isolated rows

A single sign-in event may be benign; a sign-in followed by a password change and an MFA change is materially different. When reviewing Security History, group events by time proximity and apparent device/location continuity. A suspicious cluster might include a new sign-in from an unfamiliar device, a passkey change shortly afterward, and then a sign-out or session activity. A benign cluster might include a normal sign-in, a user-initiated password update after receiving a password-manager alert, and a sign-out from an old browser.

Use a 30-minute cluster window for initial review, then widen it if the facts suggest a longer sequence. For example, if an unfamiliar sign-in appears at 09:10 and a password change appears at 11:45, do not automatically join those events. First ask whether the user was active, whether a password reset or support process occurred, whether the same device appears, and whether any other security-setting changes bridge the gap.

Events that create or preserve future access deserve extra weight. A sign-out may be routine. A password change, MFA change, or passkey change can alter who controls future authentication. OpenAI’s account-security guidance recommends changing an exposed, reused, or shared password when compromise is suspected; therefore, if the password change itself was not user-initiated, treat it as a high-priority event even if the approximate location looks familiar.

Normalize sign-ins and sign-outs before escalating

Sign-ins should be compared against the account owner’s normal authentication pattern: primary browser, mobile app, operating system, work device, personal device, password manager, VPN, and corporate network. A familiar device at an unusual hour may be lower risk than an unfamiliar device during business hours, but neither field is decisive. Ask the account owner to confirm whether they were using ChatGPT at that time without asking them to reveal passwords, MFA codes, passkey prompts, session tokens, or other secrets.

Sign-outs are often less severe than sign-ins because they usually reduce active access, but they can still matter in a sequence. If an unfamiliar sign-in is followed by a sign-out from a known device, it could mean the user cleaned up sessions, or it could indicate account-control activity by someone else. Record the sequence and ask whether the user performed a “log out all sessions” action or manually signed out from a device.

If the account is used across browser profiles, mobile apps, or shared family devices, document that baseline. Shared-device ambiguity is especially common for households, classrooms, and small businesses. For children or students, guardians and educators should avoid accusatory conclusions from approximate data and should focus on account safety: update credentials, review MFA or passkey settings, and ensure the young user knows not to share passwords or approve unexpected prompts.

Review password-change events as control-boundary events

A password change is not merely another account event; it changes the control boundary. If the account owner initiated the change after discovering a reused password, that can be protective. If the owner did not initiate it, the event suggests that someone may have gained enough access to alter authentication. In the second case, move from observation to containment: change the password again from a trusted device and follow OpenAI’s recommendation to log out of all sessions when unrecognized activity is seen.

Use a trusted device and network for any corrective password change. Do not change passwords from a device suspected of malware, a shared kiosk, or a browser profile with unknown extensions. If a workplace account may be involved, coordinate with the organization’s IT or security team before making changes that could destroy useful evidence or conflict with company incident-response procedures.

For password-manager users, add two checks. First, confirm whether the saved ChatGPT or OpenAI password was reused elsewhere, because OpenAI’s guidance specifically calls out exposed, reused, or shared passwords as a reason to change it. Second, check whether the password manager shows a recent update time that matches the Security History password-change event. This does not prove safety, but it can corroborate whether the account owner performed the change.

Review MFA changes with a presumption of caution

MFA changes deserve heightened attention because they affect the second factor used to protect future sign-ins. If Security History shows a change to MFA and the user does not remember making it, treat the event as suspicious even when the sign-in location is approximate or familiar. Attackers who gain account access often try to alter recovery or authentication settings to maintain access; defenders should avoid debating exact geography before reducing exposure.

Ask a narrow confirmation question: “Did you intentionally change your MFA settings at this date and approximate time?” Do not ask the user to send MFA backup codes, screenshots containing codes, authenticator seeds, or recovery material. If a screenshot is necessary for internal evidence, redact codes and secrets before storing it, and follow the organization’s evidence-retention rules.

If the account belongs to a company, an MFA change may also have policy implications. Enterprise administrators should check whether the event conflicts with workspace security requirements, identity-provider policy, or internal access-review expectations. Do not assume that ChatGPT-visible Security History contains every identity event from an external identity provider; compare it with authorized internal logs when available.

Review passkey changes as device-and-identity events

Passkey changes should be reviewed as both account-security events and device-trust events. A passkey is typically associated with a user-controlled device, platform account, browser, or credential manager. If Security History shows a passkey change, ask whether the user recently added a new phone, laptop, browser profile, platform account, or password manager. If the answer is no, elevate the event because an unauthorized passkey could provide a durable sign-in path.

Keep the review focused on control, not implementation assumptions. Do not infer the exact passkey storage provider or device model unless the visible details support it. Security History may show device details, but OpenAI notes that some details may be approximate or unavailable. Record the displayed device information exactly, then separately record the reviewer’s hypothesis: “May correspond to user’s new laptop” or “No known matching device.”

For families and schools, passkey changes can be confusing because platform prompts may appear during routine device setup. A parent or educator should verify whether the user recently followed an operating-system or browser prompt, but should not ask a minor to share private device credentials. The safe action is to ensure the account is under the intended owner’s control, remove unrecognized authentication methods where the product allows, and contact support if the account history suggests unauthorized control.

This ChatGPT Work cloud-browser guide covers secure login, site permissions, confirmation gates, and session cleanup on signed-in websites, offering practical context for reviewing and terminating active authenticated sessions. The Use ChatGPT Work Cloud Browser on Signed-In Websites: Secure Login, Site Permissions, Confirmation Gates, and Session Cleanup article is a focused companion for Session Management because the target concerns login sessions and cleanup rather than Codex conversation context, making it a defensible bridge for account-session management after an unfamiliar security event.

Compare devices with a baseline inventory, not memory alone

Memory is unreliable during a security scare. Build a lightweight device baseline for the account before deciding that a device is unfamiliar. The baseline should include normal browsers, mobile devices, work computers, personal computers, VPN use, password managers, and whether the user signs in from multiple regions because of travel or corporate networking. For a founder or executive, include assistant-managed devices only if they are authorized and documented.

The baseline should not collect unnecessary serial numbers, personal identifiers, or private data. A practical inventory can use coarse labels: “Work MacBook in Chrome,” “Personal iPhone app,” “Company Windows laptop through VPN,” or “Home tablet used by parent and child.” The purpose is to identify mismatches, not to build a surveillance database.

Do not overinterpret approximate location

Approximate location is useful for triage, but it is not proof of where a person physically sat. Network routing, VPNs, mobile carriers, enterprise proxies, and geolocation databases can all produce surprising city, region, or country labels. OpenAI’s release-note description allows for location details, while its security guidance cautions that some details may be approximate or unavailable. That means location should inform the review, not decide it alone.

A conservative decision rule is to treat location as a supporting clue. If the device, time, and event type are all normal, a surprising but plausible location may be logged as “explainable with uncertainty.” If the location is surprising and the device is unknown, raise severity. If the location is surprising, the device is unknown, and the event changes password, MFA, passkeys, or API access, act first and analyze later.

Avoid statements such as “the account was accessed from a specific address” unless an official source actually provides that precision and your organization is authorized to use it. In most account-history reviews, the safer wording is “Security History displayed an approximate location of X” or “location details were unavailable.” That phrasing preserves evidence integrity and prevents downstream legal, HR, or family decisions from resting on overstated technical data.

Record uncertainty explicitly

Every triage note should separate observed facts from interpretation. An observed fact is “Security History shows a sign-in at 14:08 with device detail Y and location detail Z.” An interpretation is “this may be the user’s new phone.” A conclusion is “expected,” “unresolved,” “suspicious,” or “urgent.” Mixing these categories creates confusion, especially when support, IT, legal, or a parent later reviews the record.

Use uncertainty labels that are operationally meaningful. “Confirmed expected” means the account owner recognizes the event and the event type is consistent with known behavior. “Plausibly expected” means there is a credible explanation but not enough confirmation. “Unresolved” means no conclusion yet. “Suspicious” means enough mismatch exists to trigger containment. “Urgent” means account-control or API exposure may be active and immediate protective action is needed.

Uncertainty labels for Security History review

Confirmed expected:
User confirms event; time, device, and event type fit known behavior.

Plausibly expected:
A reasonable explanation exists, but one or more fields remain unclear.

Unresolved:
Reviewer lacks enough information; preserve evidence and continue checking.

Suspicious:
User does not recognize event, or event conflicts with known behavior.

Urgent:
Suspicious event includes password, MFA, passkey, session persistence, API key exposure,
or other access-control risk requiring immediate containment.

Severity matrix for unfamiliar activity

The following matrix is a recommended triage model, not an OpenAI severity classification. It is designed to help individuals, administrators, and security teams decide when to observe, verify, contain, or escalate. OpenAI’s documented compromise guidance remains the core action sequence when unrecognized activity appears: change exposed, reused, or shared passwords; log out of all sessions; delete affected API keys; inspect API usage; preserve useful details; and contact OpenAI Support.

For enterprise administrators, severity should account for the user’s role. A suspicious sign-in for a billing administrator, workspace owner, developer with API keys, legal-team member, educator managing student work, or executive with sensitive conversations may require faster escalation than the same ambiguity on a low-risk test account. Role-based severity is a local governance decision; do not assume Security History itself assigns business impact.

Evidence log template for account review

An evidence log protects both speed and accuracy. It prevents repeated questioning of the account owner, gives support or internal security a concise timeline, and preserves the distinction between displayed Security History data and reviewer inference. It should not contain passwords, tokens, MFA codes, passkey secrets, private keys, or unnecessary personal content. If screenshots are used, redact unrelated conversations, personal identifiers, and any visible sensitive material not needed for the case.

Copyable evidence log entry

Event label:
Displayed event type:
Displayed time:
Time-zone assumption:
UTC conversion:
Displayed location:
Displayed device:
Related events within 30 minutes:
Account owner confirmation:
Known benign explanations:
Contradicting facts:
Risk rating:
Containment actions taken:
Evidence preserved:
Open questions:
Next reviewer/owner:

Triage unfamiliar activity in the right order

When activity is unfamiliar, the order of operations matters. Do not spend the first hour debating whether an approximate city is correct while a suspicious session or API key may remain usable. The safer sequence is to preserve enough visible evidence, reduce future access, review credentials and authentication methods, inspect API exposure if applicable, and then continue root-cause analysis.

1. Preserve the visible facts. Record Security History entries, times, device details, location details, and the account owner’s recognition status. Use screenshots only if allowed and redact unrelated sensitive information.
2. Check whether the event changed control. Prioritize password, MFA, passkey, and security-setting changes over ordinary sign-outs.
3. Use a trusted device for corrective action. Avoid changing credentials from a device suspected of malware or from a shared public machine.
4. Change exposed, reused, or shared passwords. OpenAI recommends changing such passwords when unrecognized activity is seen or compromise is suspected.
5. Log out of all sessions. This reduces the chance that an unrecognized active session continues to access the account.
6. Review MFA and passkeys. Confirm that only expected authentication methods remain associated with the account where the interface and plan allow review or changes.
7. Delete affected API keys and inspect usage. If API keys may be exposed or misused, OpenAI recommends deleting affected keys and reviewing API usage.
8. Contact OpenAI Support when needed. Preserve relevant Security History details and provide a concise timeline rather than speculation.

For companies, do not let individual users privately resolve a potentially business-impacting compromise if the account touches customer data, internal documents, regulated workflows, legal matters, production systems, billing, or API keys. Local policy should define when the security team, legal team, privacy office, or workspace administrator must be notified. This guide is practical account-security guidance, not legal advice or a substitute for an incident-response plan.

Special triage paths for developers and API-key users

Developers should treat unfamiliar account activity as potentially relevant to API keys even if Security History does not show API-key creation or use in the same row. OpenAI’s account-security guidance specifically recommends deleting affected API keys and reviewing API usage when compromise is suspected. If an API key was stored in a local environment, CI system, notebook, server, repository secret, or developer machine that might be exposed, rotate it rather than trying to prove misuse first.

Do not paste API keys into ChatGPT, support messages, tickets, screenshots, logs, or internal chat. A safe evidence record can say “Key ending in locally recorded suffix was deleted” if your organization’s secret-management policy permits partial identifiers, but it should not include the full secret. When in doubt, identify keys by creation date, owner, project, or internal vault reference rather than by secret value.

For teams, pair account triage with a usage review. Look for unexpected volume, unexpected timing, unfamiliar applications, or activity inconsistent with deployment schedules. Do not invent a usage conclusion if the data is incomplete; record “no abnormal usage found in reviewed window” or “usage review pending” rather than “no misuse occurred.” The latter is stronger than the evidence usually supports.

Special triage paths for founders, executives, and administrators

Founder and administrator accounts often concentrate risk: billing access, workspace settings, customer information, confidential strategy, investor materials, or connected developer workflows may all be nearby. If Security History shows an unrecognized sign-in or security-setting event for such an account, treat it as high severity until proven otherwise. The containment burden is justified because control-plane accounts can affect other users and systems.

Administrators should avoid taking destructive or broad permission-changing actions without appropriate authorization unless emergency policy permits it. For example, disabling access, resetting credentials, revoking keys, or changing workspace policies may be necessary, but those steps can disrupt business operations and evidence collection. A mature workflow assigns an incident commander or accountable owner before making sweeping changes.

For legal-technology teams, preserve privilege and confidentiality boundaries. A security review should not require broad reading of legal conversations or matter documents unless authorized and necessary. If a potentially compromised account touched legal work, involve qualified counsel or the organization’s legal team under local policy. Do not treat this guide as legal advice about breach notification, privilege, employment action, or client communication.

Special triage paths for educators, parents, and shared environments

Educators and parents should use Security History to improve account safety, not to conduct unsupported attribution. Shared devices, school networks, home tablets, browser profiles, and VPNs can all make device and location clues ambiguous. The first question should be whether the account remains under the intended user’s control and whether authentication settings are appropriate for the user’s age, role, and institutional policy.

If a student or child sees unrecognized activity, do not ask them to disclose passwords, MFA codes, passkey prompts, or private recovery information. Help them change an exposed or reused password from a trusted device, review active sessions, and involve the school administrator or guardian where appropriate. If there is concern about coercion, harassment, exploitation, or personal safety, involve qualified real-world support according to school, family, and local safeguarding procedures.

In classroom settings, record only the minimum necessary facts: account identifier under school policy, event type, approximate time, whether the student recognizes the activity, and safety action taken. Avoid publishing screenshots or discussing suspected account compromise in group channels. Account security events can expose sensitive personal context, and approximate location should never be used as a disciplinary finding by itself.

When to contact OpenAI Support

OpenAI recommends contacting Support when unrecognized activity or suspected compromise is identified after preserving relevant Security History details and taking protective actions such as changing risky passwords, logging out sessions, and deleting affected API keys where applicable. A useful support report is concise: it states the visible event sequence, what the user recognizes, what actions have already been taken, and what remains unresolved.

Do not send support a password, MFA code, passkey secret, API key, session cookie, private key, government identifier, payment number, health information, student record, legal matter content, or unnecessary confidential document. If support needs additional information, provide only what is requested and safe to share. Redact screenshots to the event details needed for account review.

Support-ready summary template

Subject:
Potential unrecognized account activity in Security History

Account:
Plan/workspace context, if relevant:
Approximate review time:
Events observed:
- Event type, displayed time, displayed location, displayed device
- Event type, displayed time, displayed location, displayed device

What the user recognizes:
What the user does not recognize:
Containment actions already taken:
- Password changed from trusted device? yes/no
- Logged out all sessions? yes/no
- MFA/passkeys reviewed? yes/no
- Affected API keys deleted? yes/no/not applicable
- API usage reviewed? yes/no/not applicable

Evidence preserved:
Open questions:
Requested assistance:

Decision rules that prevent both panic and complacency

A disciplined review uses thresholds. If the event is recognized and does not alter control, record it and move on. If one field is unfamiliar but there is a credible benign explanation, verify and watch for related events. If the user does not recognize a sign-in, treat it as suspicious. If the user does not recognize a password, MFA, passkey, or other security-setting change, treat it as urgent. If API keys may be affected, delete and rotate the affected keys rather than waiting for definitive proof of misuse.

Do not promise recovery or certainty. Security History can help

Contain suspected compromise first: the documented order of operations

OpenAI’s account-security guidance gives a practical sequence for users who notice unrecognized activity: change an exposed, reused, or shared password; log out of all sessions; review account security controls such as MFA and passkeys; delete affected API keys; inspect API usage; preserve useful details; and contact OpenAI Support. Treat that order as a containment workflow, not a forensic conclusion. Security History can surface recent sign-ins, sign-outs, password changes, MFA changes, passkey changes, and other security-setting events with time, device, and location details, but OpenAI notes that some details may be approximate or unavailable, so the safe move is to reduce access first and analyze uncertainty second.

The containment mindset is simple: if a password may be known outside your control, if a session may be active on a device you do not control, or if an API key may exist in a repository, ticket, notebook, terminal transcript, prompt, screenshot, vendor workspace, or shared document, assume continued access is possible until you revoke or replace the relevant credential. Do not wait to prove malicious intent before changing a credential that was exposed, reused, or shared. Do not rely on approximate location as the only reason to dismiss an event. Do not assume that deleting a browser cookie or closing a laptop ends every active session.

Operational rule: containment actions should remove future access without destroying the information needed to understand what happened. Change weak or exposed passwords, end sessions, revoke affected API keys, and preserve timestamps, event descriptions, usage observations, and support-relevant context before memories fade.

Step 1: Change an exposed, reused, or shared password

If your ChatGPT or OpenAI account password has ever been reused on another service, shared with another person, stored in an insecure location, sent through chat or email, or found in a credential breach notification, replace it with a unique password. A password manager can generate and store a long unique password, but do not paste the password into ChatGPT, a support ticket, a shared incident document, a code repository, or a team messaging channel. The goal is to make the old secret useless without creating a new exposure path.

Change the password from a trusted device and a trusted network when possible. If you suspect the device itself may be compromised, move to a clean managed device or a newly updated personal device before changing credentials. A password change performed on a malware-infected endpoint can immediately expose the replacement secret. Enterprise administrators should follow their internal endpoint-response procedure before using the device for any credential reset, especially if the same machine stores developer tokens, SSH keys, browser profiles, password-manager sessions, or administrative cookies.

Use a decision rule rather than intuition. If the password was unique, stored only in a reputable password manager, and the suspicious activity appears explainable by a known device or travel pattern, a password change may still be prudent but is not the only containment measure. If the password was reused, copied into a document, known by a former employee, typed on an unmanaged public computer, or stored in source control, change it immediately and continue through the rest of the sequence. A password reset alone does not necessarily invalidate every active session or every API key, so do not stop after this step.

Step 2: Log out all sessions before resuming normal use

OpenAI recommends logging out of all sessions when you see unrecognized activity. In practical terms, ending sessions reduces the chance that an already-authenticated browser, desktop app, mobile app, or other active client remains usable after you have changed a password. This is especially important for shared computers, lost devices, former contractors’ machines, lab computers, classroom carts, conference kiosks, remote desktops, and browsers synchronized across profiles.

After signing out sessions, sign back in only from devices you currently trust and can physically or administratively account for. If you are a founder or administrator coordinating a response, avoid asking team members to “check whether they can still get in” from unknown devices, because that creates confusing logs and may extend the investigation surface. Instead, assign one account owner or security lead to perform the recovery actions, record the steps taken, and notify authorized stakeholders using approved internal channels.

Session termination is not a substitute for API-key rotation. Browser or app sessions and API credentials are separate forms of access in most operational models, and OpenAI’s guidance separately calls out deleting affected API keys and reviewing API usage. A developer account can look clean in a human sign-in review while a leaked key continues to be used by an integration, build job, notebook, script, or third-party service. Conversely, an API-key exposure does not prove a browser session was taken over. Keep the two tracks distinct and contain both when warranted.

Step 3: Review MFA and passkeys as control changes, not decorations

Security History can show changes to MFA, passkeys, and other security settings. Treat any unfamiliar MFA or passkey change as a high-value event because these controls affect who can authenticate later. If a new passkey appears around the same time as an unfamiliar sign-in, or if MFA settings changed shortly after a password event, escalate the review even if location details are approximate. A control change can be more consequential than a single sign-in because it may alter the future authentication path.

Review your current MFA and passkey configuration after changing the password and ending sessions. Remove any authentication method, passkey, device binding, or recovery path that you cannot identify. Do not delete all recovery options casually if doing so could lock out the legitimate account owner; instead, confirm the known-good methods first, then remove unknown or obsolete methods. In a family, classroom, or small-company environment, document who is authorized to hold recovery capability so that a well-intentioned helper does not become an unmanaged identity risk.

For enterprise administrators and security teams, the important question is not only “was MFA enabled?” but “who could satisfy the second factor, on which device, under which policy, and since when?” If your organization has identity-provider logs, mobile-device-management records, or endpoint inventory, compare those records with the approximate device and timing clues shown in Security History. Do not claim that Security History proves exact device identity or exact geolocation; use it as an account-facing timeline to correlate with authoritative internal logs.

The article discusses AI agent security risks, credential management, and containment strategies for real systems operated by autonomous agents. The AI Agents Are Hacking Real Systems: Complete Guide to AI Agent Security, Credential Management, and Containment in 2026 article is a focused companion for Compromised Credential Response because credential compromise response requires containment and credential-management thinking, making this the strongest available match among the allowed incident-response and security candidates.

Step 4: Delete affected API keys, then replace only what you still need

OpenAI’s guidance specifically tells users who suspect compromise to delete affected API keys and review API usage. For developers, this is the step where account recovery becomes production-risk management. An API key may be embedded in a local environment file, continuous-integration secret store, server configuration, notebook, command history, shell profile, proxy, mobile build, analytics job, customer demo, vendor integration, or old proof-of-concept. If that key was exposed or might have been copied, revoke it rather than trying to determine whether every copy was recovered.

Never print the full API key in an incident channel, rotation ticket, spreadsheet, screenshot, or prompt. Identify keys by safe metadata such as creation date, owner, project, service name, environment, last known usage pattern, internal secret name, or a short non-sensitive label. If your tooling displays a key prefix or masked form, use only the minimum non-secret identifier needed for coordination. The incident record should allow the team to rotate the credential without turning the incident document into another secret store.

If you operate production systems, avoid a chaotic “delete everything now” response unless the risk warrants emergency shutdown. A better default is fast inventory, immediate revocation of clearly exposed keys, staged replacement of keys needed for critical services, and explicit human approval for any customer-visible restart. If you cannot determine which key was exposed, the conservative path may be to rotate all keys associated with the account or workspace, but that decision should include the operational owner because it can interrupt jobs, demos, support workflows, and applications.

The article provides prompt workflows for OpenAI workspace administrators covering model access, group provisioning, Codex audits, and key-rotation runbooks. The 25 ChatGPT-5.5 Prompts for OpenAI Workspace Admins: Model Access, Group Provisioning, Codex Audits, and Key Rotation article is a focused companion for API Key Rotation because it directly names key rotation and administrator runbooks, matching a section about rotating OpenAI API keys after risk or routine security review.

Build a dependency inventory before and during rotation

A dependency inventory is the map that prevents credential rotation from becoming an outage. At minimum, list each application or workflow that uses an OpenAI API key, the environment where it runs, the owner who can deploy a change, the secret-storage location, the expected call pattern, and the verification method after replacement. Do not wait for a suspected compromise to create this inventory. Build it during normal operations, then update it during incidents when you discover forgotten notebooks, old demos, scheduled scripts, or personal automation.

For founders and small teams, the inventory can begin as a controlled internal table with columns for service, owner, environment, secret label, rotation date, and verification status. For larger organizations, use the existing configuration-management database, secret-management platform, service catalog, or incident-management system. The important property is not format; it is whether an authorized person can answer, under pressure, “which systems will fail if this key disappears, and who can safely replace it?”

Recommended dependency-inventory fields, without secrets:

Service or workflow:
Business owner:
Technical owner:
Environment: development | staging | production | demo | classroom | research
Secret-manager label or CI variable name:
OpenAI account or workspace owner:
Expected usage pattern:
Customer-visible impact if revoked:
Rotation priority: emergency | same day | scheduled
Replacement deployment method:
Verification check:
Rollback or disablement plan:
Last reviewed date:
Incident notes:

Inventory work must not become an excuse to keep a known-exposed key alive indefinitely. Use a time-boxed approach: immediately revoke keys confirmed to be public or shared outside authorization; inventory the remaining uncertain keys; rotate high-risk or high-privilege keys first; then rotate lower-risk keys according to a documented schedule. If a production service depends on a possibly exposed key and cannot be rotated quickly, consider disabling the dependent feature, restricting its use, or placing it behind additional monitoring until replacement is complete.

Plan rotation so you do not create a second incident

Credential rotation can fail in two predictable ways: teams revoke too slowly and leave access open, or they revoke too broadly without knowing the blast radius. A disciplined rotation plan reduces both risks. Create the replacement key only in the approved account or workspace, store it directly in the approved secret manager, deploy it through the normal release mechanism when feasible, verify the service with minimal test traffic, and revoke the old key after the replacement is confirmed. In an emergency, you may need to reverse the order and revoke first, but document the reason and expected service impact.

Do not paste a new key into ChatGPT to ask whether it “looks correct,” do not send it to a contractor over chat, and do not store it in a project-management card. If an assistant, teammate, or support process asks for the raw key, treat that as a process failure. Support and incident collaborators generally need metadata, timestamps, error descriptions, account context, and usage observations, not the secret itself. If a key value appears in logs or screenshots during the response, treat that copy as a new exposure and rotate again.

Use a two-person review for production rotation when possible: one person updates the secret and deploys, another verifies configuration, logs, and service behavior without viewing the raw secret unnecessarily. For small teams, the same principle can be approximated by separating tasks: the owner stores the key in the secret manager, and a reviewer checks that the application reads the named secret, not a hard-coded local value. For regulated, legal, education, youth, or enterprise contexts, include the appropriate privacy, security, or compliance owner before resuming workflows that process sensitive information.

Inspect API usage after revocation and replacement

OpenAI’s guidance includes reviewing API usage after deleting affected keys. Usage inspection is not the same as proving who used a key, and it should not be overstated as complete forensics. Look for practical anomalies: unexpected spikes, activity during unusual hours, calls from services that should be inactive, usage after a demo ended, usage from a development key that should not support production volume, or billing patterns inconsistent with your known workflows. Preserve observations in a concise evidence log rather than copying sensitive request content into an incident document.

When reviewing usage, compare against a baseline. A batch job, evaluation run, classroom exercise, product launch, or scheduled automation may create legitimate bursts that look suspicious in isolation. Conversely, a small amount of unauthorized use may be easy to miss if you only look for dramatic spikes. Ask service owners what should have run during the relevant window, then mark each activity cluster as expected, unexplained, or under review. Avoid definitive labels such as “attacker” or “breach confirmed” unless you have evidence from appropriate logs and qualified responders.

If your organization uses centralized logging, keep the review focused on minimum necessary information. You may need timestamps, service names, status codes, aggregate counts, deployment identifiers, and internal request IDs. You usually do not need to duplicate full prompts, uploaded content, customer records, student information, legal matter details, health information, or personal identifiers into a security-history write-up. When sensitive logs are required for a formal investigation, handle them under your organization’s approved evidence and access-control process.

Preserve useful details without collecting unnecessary private content

OpenAI recommends preserving relevant Security History details before contacting Support. The useful details are the ones that help establish a timeline and identify affected controls: event type, visible time, approximate location if shown, device detail if shown, whether the event is recognized, what containment steps were taken, which API keys were deleted or rotated by safe label, and what usage windows appeared unusual. Because OpenAI notes that some details may be approximate or unavailable, record the uncertainty rather than converting it into a false claim.

Support-ready incident summary template:

Account or workspace context:
Date and time zone used for review:
Unrecognized Security History events:
Known legitimate events in the same window:
Password changed: yes/no, time:
All sessions logged out: yes/no, time:
MFA/passkey review completed: yes/no, findings:
Affected API keys deleted or rotated by safe label:
API usage windows reviewed:
Unusual usage observed:
Devices or users still under review:
Screenshots preserved: yes/no, redacted if needed:
Business impact observed:
Support question or requested assistance:

Do not include passwords, API keys, passkey material, authentication codes, recovery codes, private customer content, privileged legal material, student records, health information, or unnecessary personal identifiers in the summary. If screenshots are necessary, crop or redact unrelated private content. If an enterprise incident may involve regulated data, legal obligations, or contractual notification duties, involve qualified security, privacy, legal, and compliance professionals. This guide is account-security guidance, not legal advice and not a certification that a reportable incident has or has not occurred.

Contact OpenAI Support with a concise timeline and containment status

After containment and evidence preservation, contact OpenAI Support when activity remains unrecognized, when API usage appears suspicious, when security settings changed without authorization, when you cannot regain normal control, or when the account belongs to an organization with operational, educational, legal, or customer-facing responsibilities. A concise support request is more useful than a large unstructured narrative. State what you saw, when you saw it, what you changed, what you revoked, what remains uncertain, and what help you need.

Keep the support request factual. Good phrasing is: “Security History showed an unrecognized sign-in at approximately this time; I changed the password, logged out all sessions, reviewed MFA and passkeys, deleted these affected API keys by safe label, and observed unusual API usage during this window.” Avoid unsupported conclusions such as “OpenAI was breached,” “the location proves the attacker,” or “all data was accessed,” unless you have authoritative evidence. Support can work more effectively from clear observations than from speculation.

If you are responding for a company, school, nonprofit, law firm, or public agency, coordinate who is allowed to communicate with Support. Multiple people submitting overlapping tickets can create inconsistent timelines and duplicate handling. Assign an incident owner, maintain an internal evidence log, and ensure any external statements, customer notifications, legal commitments, regulator communications, or public posts receive qualified human approval through your normal governance process.

Containment workflow checklist for different account types

The same documented sequence applies broadly, but the operational emphasis changes by account type. An individual knowledge worker usually focuses on password uniqueness, session termination, MFA or passkey review, and any personal API keys. A developer must add dependency mapping, key revocation, usage review, and deployment verification. An administrator must coordinate identity, endpoint, support, and stakeholder communication. A parent or educator must consider shared devices and youth access without turning a child or student into the incident manager.

Recovery is not complete until old access paths are closed

A common mistake is to declare recovery complete after a successful sign-in with the new password. In a real operational environment, old access paths can include active sessions, unknown passkeys, stale MFA devices, API keys in scripts, keys copied into vendor tools, keys embedded in local notebooks, and credentials stored on lost or unmanaged devices. Close each class of access path deliberately, then record the closure. If a class does not apply to your account, mark it “not applicable” rather than leaving it blank.

Use a final recovery review before resuming sensitive work. Confirm that the password is unique, all sessions were logged out, MFA and passkeys are recognized, affected API keys were deleted or rotated, applications using replacement keys were verified, usage was inspected for the relevant window, useful evidence was preserved, and Support was contacted if activity remains unexplained. For teams, require the incident owner to state what is known, what remains unknown, and what monitoring will continue. This prevents a vague “looks fine now” from replacing an accountable closure decision.

Finally, convert the incident into a prevention backlog. Add missing services to the dependency inventory, remove unused keys, shorten the list of people who can create or store credentials, improve secret scanning, document the rotation runbook, and schedule periodic Security History reviews. These are recommendations, not OpenAI product guarantees. They make future reviews faster because you will know which sign-ins, sessions, passkeys, MFA methods, and API dependencies are expected before the next alert, anomaly, or unfamiliar event appears.

Set a review cadence that matches account risk, not anxiety

Security History is most useful when it becomes a predictable review habit rather than a panic-only screen. OpenAI’s release notes describe Security History as a place on the web where users can review recent account-security events, including sign-ins, sign-outs, password changes, MFA changes, passkey changes, and other security-setting activity with time, location, and device details where available. Those records can support practical account review, but they should not be treated as a complete forensic system, a legal record, or proof that an account is safe or compromised.

The right cadence depends on what the account can do. A personal ChatGPT account used for drafting notes has a different risk profile from a developer account with API keys, a founder account connected to sensitive business discussions, or an educator account used around minors and shared devices. The review schedule below is a recommendation, not an OpenAI requirement, and should be adjusted for workspace policy, regulatory obligations, device-sharing patterns, and the sensitivity of stored conversations or connected workflows.

A cadence should include both a “quiet review” and a “triggered review.” Quiet review means opening Security History and related account-security pages on a planned schedule, checking for obvious anomalies, and recording only the minimum notes needed to establish that a review occurred. Triggered review means responding to a signal such as a password-manager breach alert, unusual API usage, a lost device, an unexpected sign-in, or a security-setting change that the account owner does not recognize.

Do not make review frequency so burdensome that users stop doing it. A monthly personal review with clean notes is more reliable than an elaborate daily procedure that nobody follows. For developers, administrators, and small businesses, the most important discipline is not merely frequency; it is making sure API keys, sessions, passwords, MFA, and passkeys are reviewed together because compromise often becomes visible through a pattern rather than a single row.

The article is a complete guide to OpenAI Advanced Account Security for ChatGPT and Codex users, focused on protecting OpenAI accounts in professional and personal workflows. The Complete Guide to OpenAI’s Advanced Account Security for ChatGPT and Codex Users article is a focused companion for Account Security Checklist because a checklist section should point readers to a broader account-security guide, and this target is the most comprehensive allowed candidate without reusing the passkey-specific selection.

Evidence templates that preserve useful facts without collecting excessive private data

OpenAI recommends preserving relevant Security History details when a user sees unrecognized activity and needs to contact Support. Preservation should be targeted: keep enough information to describe the account, timeline, affected controls, and containment steps, but avoid copying unnecessary personal content, conversation text, customer data, student data, health information, payment information, tokens, passwords, or secret keys into an evidence log.

The best evidence template separates observable facts from assumptions. “Security History showed a sign-in at an approximate location I do not recognize” is an observable statement. “An attacker in that city stole my account” is an unsupported conclusion unless separate evidence proves it. Because OpenAI notes that time, location, and device details may be approximate or unavailable, evidence notes should preserve uncertainty rather than convert approximate signals into definitive attribution.

Template: personal or knowledge-worker account review note

Account review note — personal ChatGPT account

Reviewer:
Review date and time:
Reason for review:
Time zone used for notes:

Security History observations:
- Sign-ins reviewed from:
- Sign-outs reviewed from:
- Password changes observed:
- MFA changes observed:
- Passkey changes observed:
- Other security-setting changes observed:
- Details that were approximate or unavailable:

Recognized activity:
- Event:
- Why it is recognized:
- Supporting context, if any:

Unrecognized or uncertain activity:
- Event:
- Why it is unfamiliar:
- Device/location/time details shown:
- Alternative benign explanations considered:

Containment steps completed:
- Password changed if exposed, reused, or shared:
- Logged out of all sessions:
- MFA/passkeys reviewed:
- API keys reviewed, if applicable:
- Support contacted, if applicable:

Remaining actions:
- Monitor account:
- Check password manager:
- Review device security:
- Follow up with organization, school, or support:

Template: developer API-key review note

Developer/API security review note

Reviewer:
Project or application:
Review date and time:
Reason for review:
Time zone:

Potential exposure source:
- Repository:
- CI/CD system:
- local machine:
- shared document:
- logging system:
- contractor/vendor environment:
- unknown:

Security History observations:
- Relevant sign-ins:
- Relevant sign-outs:
- Password/security-setting changes:
- MFA/passkey events:
- Details approximate or unavailable:

API key review:
- Keys identified as affected:
- Keys deleted:
- Replacement keys created only for active dependencies:
- Services updated:
- Services not yet updated:
- Old keys confirmed no longer in use:
- API usage reviewed for unexpected activity:

Containment:
- Password changed if needed:
- Logged out of all sessions:
- Development machines checked:
- Secrets removed from unsafe locations:
- Support contacted if needed:

Verification:
- Application works with replacement key:
- No known system still uses deleted key:
- Usage pattern after rotation reviewed:
- Follow-up review scheduled:

Template: administrator or small-business incident note

Small-business or administrator account-security note

Organization/workspace:
Account owner:
Reviewer:
Approver:
Review date and time:
Trigger:

Business impact assessment:
- Customer data involved? Unknown / No / Yes, describe without sensitive details:
- Employee data involved? Unknown / No / Yes, describe without sensitive details:
- API or automation involved? Unknown / No / Yes:
- External messages, payments, publications, bookings, or commitments affected? Unknown / No / Yes:

Security History summary:
- Unrecognized sign-ins:
- Sign-outs:
- Password changes:
- MFA changes:
- Passkey changes:
- Other security-setting changes:
- Approximate/unavailable details:

Containment actions:
- Password changed:
- Sessions logged out:
- MFA/passkeys reviewed:
- API keys deleted/replaced:
- Usage inspected:
- Devices checked:
- Internal stakeholders notified:
- OpenAI Support contacted:

Human approval gates:
- No external customer notice sent without approval:
- No legal notice sent without counsel/authorized leadership:
- No payment, refund, purchase, booking, or publication made automatically:
- No permissions changed beyond approved containment:

Next review:
- Date:
- Owner:
- Open issues:

For legal, education, healthcare, finance, or regulated environments, this template is only an operational starting point. It is not legal advice, does not determine notification duties, and does not certify compliance with any law, contract, framework, or regulator’s expectations. Organizations should use counsel, privacy officers, security teams, school leadership, or other qualified professionals when the facts may create legal, contractual, safeguarding, or regulatory obligations.

Handle false positives without normalizing real risk

False positives are common in account review because legitimate activity can look unfamiliar after travel, VPN use, mobile-network routing, browser updates, device replacement, shared-family devices, office hot-desking, or password-manager autofill on a new machine. OpenAI’s note that some Security History details may be approximate or unavailable is important: approximate location should be treated as a clue, not as a precise address, identity, or proof of compromise.

A conservative false-positive process has three steps. First, ask whether the user can connect the event to a known action at about the same time, such as signing in from a hotel, changing a phone, enrolling a passkey, clearing cookies, or using a different browser. Second, compare the event to stronger controls: did a password change, MFA change, passkey change, API-key action, or unexpected session pattern appear nearby? Third, if the user remains uncertain, apply containment steps that reduce future access without making unsupported accusations.

False-positive handling should never become a reason to ignore a high-risk control change. A passkey or MFA change that the account owner does not recognize deserves more caution than a fuzzy location alone. A potentially exposed API key should be deleted even if the team hopes it was never used. The cost of rotating a key or logging out sessions is usually lower than leaving a possible access path open while debating intent.

When an event is probably benign but not fully explainable, write that conclusion plainly: “Likely benign due to travel and VPN use, but device not confirmed; logged out all sessions and will recheck in 48 hours.” That note is more useful than either overstating compromise or dismissing the event without a containment decision.

Offboarding checks for employees, contractors, students, and shared environments

Offboarding is a predictable moment of account-security risk because access assumptions change. A departing employee may no longer need access to a workspace, a contractor may have used API keys in a local environment, a teaching assistant may have signed in on a classroom device, or a family member may still have access to a shared tablet. Security History can help review recent activity, but it does not replace an identity-and-access-management process, device retrieval, contract review, or organizational offboarding policy.

For administrators and small businesses, offboarding should start with account ownership. Confirm who owns the ChatGPT or OpenAI platform account, who controls recovery email and authentication factors, whether any API keys are tied to the departing person, and whether automations depend on that person’s credentials. Do not wait until after departure to discover that a production script, customer workflow, or internal reporting process uses a key stored on someone’s laptop.

Recommended offboarding checklist

1. Confirm account scope. Identify whether the person used an individual account, a business workspace, platform API keys, shared classroom devices, browser profiles, or connected tools. Avoid asking the person to reveal passwords, tokens, or private keys.
2. Review Security History. Check recent sign-ins, sign-outs, password changes, MFA changes, passkey changes, and other security-setting events where available. Record only operationally necessary details.
3. Remove unnecessary sessions. Log out sessions where appropriate, especially when devices are shared, returned, lost, reassigned, or no longer controlled by the account owner.
4. Review MFA and passkeys. Remove authentication methods that are no longer controlled by the account owner or organization. Treat unexpected changes as an incident trigger.
5. Rotate or delete affected API keys. Delete keys associated with the departing person, exposed development environments, obsolete scripts, or unknown dependencies. Replace only the keys needed for active systems.
6. Inspect usage. Review API usage for unexpected activity before and after revocation. Usage review can indicate whether a key was active, but it should not be treated as a complete forensic conclusion.
7. Recover business artifacts through approved channels. Do not use account-security procedures to access private personal content without authorization. Follow employment, school, contract, privacy, and legal requirements.
8. Document human approvals. Record who approved access removal, key rotation, account transfer, customer communication, or operational changes.
9. Schedule a follow-up review. Recheck after rotation to confirm that old access paths did not reappear and replacement systems are operating as intended.

Educators and parents should adapt offboarding language to the environment. At the end of a course, club, school term, tutoring relationship, or shared-device arrangement, check that accounts are signed out on classroom computers, lab machines, borrowed tablets, and browsers used by multiple people. If youth safety, harassment, coercion, self-harm, exploitation, or other safeguarding concerns arise, involve qualified real-world support, school safeguarding leads, guardians, emergency services, or appropriate local resources rather than trying to resolve the situation through account settings alone.

Support escalation: what to send, what not to send, and when to involve others

OpenAI’s account-security guidance says users who see unrecognized activity should change an exposed, reused, or shared password, log out of all sessions, delete affected API keys and review API usage, preserve relevant Security History details, and contact OpenAI Support. Support escalation is most effective when the user provides a concise timeline and containment status rather than a long, speculative narrative.

Before contacting Support, complete urgent containment if doing so does not destroy needed evidence or violate organizational policy. For most individual users, that means changing a risky password, logging out sessions, reviewing MFA and passkeys, and deleting affected API keys. For an enterprise or regulated organization, internal incident-response procedures may require notifying a security team before making some changes, but leaving exposed credentials active while waiting for perfect certainty is usually unsafe.

Recommended support summary format

Subject: Unrecognized ChatGPT account activity — containment completed/underway

Account email or identifier:
Date/time issue was noticed:
Time zone:
Reason for concern:
- Unrecognized sign-in:
- Unrecognized sign-out:
- Password change:
- MFA change:
- Passkey change:
- Other security-setting change:
- API key concern:
- Usage concern:

Approximate timeline:
- [time] Event observed:
- [time] Containment step:
- [time] Follow-up observation:

Containment already completed:
- Password changed if exposed/reused/shared:
- Logged out of all sessions:
- MFA/passkeys reviewed:
- Affected API keys deleted:
- API usage reviewed:
- Evidence preserved:

What I am requesting:
- Help reviewing account-security concern:
- Guidance on next account-recovery steps:
- Assistance if I cannot access the account:

Do not include passwords, API keys, recovery codes, payment card numbers, full government identifiers, private health details, student records, confidential client documents, trade secrets, or conversation dumps unless OpenAI Support specifically requests a safer, necessary way to provide limited information. If the issue involves a business, legal matter, student, patient, customer, or regulated data, involve the appropriate internal owner before transmitting sensitive details.

Escalate beyond OpenAI Support when the facts require it. A leaked API key in a public repository may require repository cleanup and secret-scanning review. A compromised email account may require email-provider recovery because ChatGPT account recovery can be undermined if the email account remains compromised. A lost managed laptop may require mobile-device-management action. A suspected legal, privacy, contractual, or regulatory incident should be reviewed by qualified counsel or the organization’s designated privacy and security personnel. This guide is operational guidance, not legal advice or a certification of incident-response readiness.

Recovery verification: prove that old access paths are closed

Recovery is not finished when the account owner can sign in again. Recovery is finished only after old access paths have been closed, replacement access works as intended, and the account has been monitored long enough to catch obvious recurrence. Security History can help verify recent account-security activity, but it should be combined with session review, password hygiene, MFA/passkey review, API-key inventory, usage review, and device security checks.

Use a verification checklist after every suspected compromise, API-key leak, high-risk offboarding, or unexplained security-setting event. The checklist should be short enough to complete, but strict enough to prevent a team from declaring success while an old key, old browser session, old passkey, or compromised email account remains usable.

Recovery verification checklist

• Password risk resolved: The password was changed if it was exposed, reused, shared, weak, or suspected of compromise. The replacement should be unique and stored safely, preferably through an approved password manager.
• Sessions reset: All sessions were logged out where appropriate, and the user has signed back in only on trusted devices.
• MFA reviewed: MFA settings were checked, unexpected methods were removed, and recovery options are controlled by the legitimate account owner or organization.
• Passkeys reviewed: Passkeys were checked against known devices and platform accounts. Unknown or uncontrolled passkeys were removed according to the available account controls.
• API keys deleted and replaced: Affected keys were deleted. Replacement keys were created only for current, documented dependencies, not as a blanket recreation of every old key.
• Usage inspected: API usage was reviewed for unexpected activity before and after rotation. Any unexplained usage was escalated rather than ignored.
• Security History rechecked: Recent sign-ins, sign-outs, password changes, MFA changes, passkey changes, and other security-setting events were reviewed again after containment.
• Root access protected: The associated email account, password manager, device lock, operating-system updates, and browser profiles were reviewed because account recovery can fail if the surrounding identity stack remains compromised.
• Business actions reviewed: External messages, customer commitments, payments, purchases, bookings, publications, permission changes, deployments, filings, and other consequential actions were reviewed by authorized humans before any correction or communication.
• Follow-up scheduled: A second review was scheduled after a short interval, such as 24 to 72 hours for high-risk situations or the next routine review for low-risk false positives.

For developers, recovery verification should include dependency testing. Confirm that applications, jobs, and scripts use the new key and that no system is silently retrying with a deleted key. Avoid printing keys into logs, chat transcripts, tickets, screenshots, or debugging output. If a rotation causes an outage, fix the deployment process rather than restoring an old exposed key.

For administrators and small businesses, recovery verification should include an approval record. Record who approved containment, who approved replacement credentials, who decided whether external communication was necessary, and who owns the follow-up review. Do not let an AI assistant send customer notices, legal notices, employee messages, school communications, or public statements without authorized human review and approval.

Role-specific operating procedures for recurring reviews

The following operating procedures convert the cadence into repeatable actions. They are recommendations for account hygiene and triage; they are not a guarantee of recovery, a substitute for OpenAI Support, a compliance program, or a forensic investigation. Adapt them to your plan, workspace policy, local law, organization size, and risk tolerance.

Individual knowledge-worker procedure

1. Open the account-security area on the web and review Security History for recent sign-ins, sign-outs, password changes, MFA changes, passkey changes, and other security-setting events.
2. Compare unfamiliar events against travel, new devices, VPN use, browser changes, and shared computers.
3. If a password may be exposed, reused, or shared, change it to a unique password and store it safely.
4. Log out of all sessions when a device is lost, a session is unfamiliar, or the account was used on a shared machine.
5. Review MFA and passkeys and remove anything not recognized or no longer controlled.
6. If API keys are not used, confirm there are no unexpected keys. If keys are used, review them under the developer procedure.
7. Record only minimal evidence if something is uncertain, and contact OpenAI Support when unrecognized activity remains unexplained.

Developer procedure

1. Maintain a living inventory of applications, local scripts, CI/CD jobs, and services that use OpenAI API keys.
2. Review Security History on a weekly or triggered basis when projects are active, especially after secret exposure alerts or repository changes.
3. Delete affected API keys immediately when exposure is plausible, then create replacement keys only for active dependencies.
4. Inspect API usage before and after rotation for unexpected patterns, while recognizing that usage review is not a complete forensic system.
5. Remove keys from unsafe storage locations, including source code, shared notes, screenshots, logs, and chat transcripts.
6. Test production and development services after rotation, and document which systems were updated.
7. Escalate internally when customer systems, billing, regulated data, or external commitments may be affected.

Administrator procedure

1. Define who owns recurring account-security review, support escalation, evidence retention, API-key rotation, and approval of consequential actions.
2. Integrate Security History review into onboarding, offboarding, role changes, travel-risk periods, and incident-response playbooks.
3. Require human approval for external messages, permission changes, publications, purchases, payments, bookings, deployments, legal commitments, and customer notices.
4. Use evidence templates that record events and containment without collecting unnecessary confidential content.
5. Route suspected legal, privacy, employment, student, customer, or regulated-data incidents to qualified internal owners.
6. After containment, verify that sessions, authentication methods, API keys, and connected workflows align with policy.

Educator and parent procedure

1. Review account activity before and after school terms, shared-device use, device loans, travel, or changes in supervision arrangements.
2. Sign out on school, library, lab, family, or borrowed devices that are not controlled by the account owner.
3. Avoid storing passwords in shared browser profiles, classroom machines, or devices used by multiple students or family members.
4. Review passkeys and MFA with attention to who controls the device or platform account behind the authentication method.
5. Do not investigate youth-safety, harassment, coercion, exploitation, or self-harm concerns alone through account logs. Involve guardians, school safeguarding staff, emergency services, or qualified professionals as appropriate.
6. Keep notes factual and minimal, especially where minors or students are involved.

Small-business procedure

1. Create a one-page inventory of ChatGPT and OpenAI platform accounts used for sales, support, finance, product, operations, and engineering.
2. Assign an owner for each API key, automation, and account-security review process.
3. Review Security History at least biweekly for high-impact users and after travel, contractor changes, fundraising, diligence, customer-security reviews, or suspicious email activity.
4. Require approval before AI-assisted workflows send customer messages, update public pages, change permissions, launch campaigns, make purchases, book services, or commit the company externally.
5. Preserve a concise incident timeline when unrecognized activity appears, then contact OpenAI Support if the issue remains unresolved or account access is affected.
6. Schedule a recovery verification review after any suspected compromise or offboarding event.

Concluding operating principles

Security History gives ChatGPT users a practical review surface for recent account-security activity, including sign-ins, sign-outs, password changes, MFA changes, passkey changes, and other security-setting events with time, device, and location details where available. Its value comes from disciplined interpretation: treat approximate or unavailable details cautiously, review events in clusters, and prioritize containment over speculation.

The strongest response pattern is straightforward. If activity is unrecognized, change an exposed, reused, or shared password; log out of all sessions; review MFA and passkeys; delete affected API keys; inspect usage; preserve useful details; and contact OpenAI Support when needed. That sequence reduces future access before the team argues about root cause, geography, or intent.

Security History is not a complete forensic system, automatic compromise detector, legal-notification engine, or compliance certification. It is one account-security input among several: password hygiene, MFA, passkeys, session control, API-key inventory, usage review, device security, organizational approvals, and support escalation. Treat this guide as operational guidance, not legal advice, not a guarantee of recovery, and not a substitute for qualified security, legal, privacy, education, or crisis-support professionals where the situation requires them.

Useful Links

• OpenAI Help Center: ChatGPT release notes
• OpenAI Help Center: Keeping your OpenAI account secure
• OpenAI Platform: Security settings
• OpenAI Platform: API key dashboard
• OpenAI Help Center: Privacy Center in ChatGPT