ChatGPT now shows its security history. The event log is evidence, not a verdict

The new page records changes to the account boundary

OpenAI added Security history to ChatGPT on 25 September 2026. On the web, it appears under Settings → Security and login → Security history. The page shows recent security events including sign-ins, sign-outs, password changes and changes to multi-factor authentication, passkeys and other security settings.

Each event can include a time, location and device. OpenAI warns that some details may be approximate or unavailable. That qualification prevents two common mistakes: treating a nearby city as proof that an event was local, and treating an absent device detail as proof that nothing happened. IP geolocation, mobile networks, corporate egress points, VPNs and incomplete device signals can all affect what a consumer service can present.

The value of the feature is sequence. An unfamiliar sign-in followed by a passkey change is more meaningful than either event alone. A sign-out after a known device replacement may be expected. The history gives the account holder a timeline against which to test memory and other evidence.

Read the event, the context and the consequence together

A practical interpretation guide for common security-history events

Event	First benign explanation to test	Security question
Sign-in	New device, browser, app, network or travel	Was this device and time expected?
Sign-out	User action, session expiry or security change	Did it follow an event you did not authorise?
Password change	Planned credential rotation	Can you account for the request and confirmation?
MFA method added or removed	Device replacement or account hardening	Could an intruder be creating a durable route back in?
Passkey added or removed	New phone, computer or security key	Do you possess and recognise the authenticator?
Other security-setting change	A deliberate settings update	What access or recovery behaviour changed afterwards?

A location alone is weak evidence. A change to an authentication method is stronger because it alters future access. If the event list shows a sign-in followed by a new factor or passkey, respond to the whole sequence. Do not spend the first hour trying to prove which city an IP address belongs to while the unfamiliar session remains active.

Record the event type, timestamp, displayed device and location before making changes. That snapshot can help with support and later reconstruction. It should not delay containment.

The account page does not replace API-key or third-party session review

OpenAI separates Security history from Active sessions. The Active sessions documentation says rows can represent a signed-in browser or first-party OpenAI app such as ChatGPT, Codex or API Platform. It also says the view does not show or manage third-party app sessions, and may be unavailable for accounts tied to an organisation's SSO.

API keys form another access path. A person can hold a secure ChatGPT session while an exposed API key generates unauthorised usage and charges. OpenAI directs API users to delete exposed keys, review usage and keep key material outside application code. Security history should therefore sit beside session review, API-key inventory and usage monitoring rather than replace them.

For managed environments, identity-provider and workspace logs may contain the authoritative sign-in record. Consumer account history is useful evidence, but an organisation should not discard its central identity telemetry because a product now has a local page.

Which surface answers which security question

Surface	Question it answers	Important limit
Security history	What recent account-security events occurred?	Details may be approximate or unavailable
Active sessions	Which supported first-party sessions or trusted devices remain?	Does not manage third-party app sessions
API keys and usage	Can a non-interactive credential call the API and create spend?	Separate from a normal ChatGPT login session
SSO / identity provider	What did the organisation's identity boundary observe?	Depends on organisation logging and retention

An unfamiliar event needs containment before account hardening

OpenAI's response order contains one easily missed detail: enabling MFA does not cancel sessions that are already logged in. Adding a second factor protects later sign-ins but does not necessarily remove an intruder who already has a valid session.

OpenAI advises a user who suspects unauthorised access to change an exposed or reused password, log out of all sessions, delete exposed API keys, review activity and contact Support. Logging out of all sessions can take up to 30 minutes to propagate. That delay should be treated as part of containment, not as evidence that the command failed immediately.

Passkeys reduce reliance on shared secrets, but their inventory still matters. A synced passkey may appear across several devices; a local passkey can be lost with one device. Security history makes additions and removals visible, which is most useful when the user already knows which authenticators should exist.

The feature is most useful when it becomes part of a routine

A security log that is opened only after a visible compromise will still help, but it will often be late. The practical improvement is to make the page part of account changes: review it after adding a passkey, replacing a phone, enabling a new factor or signing into a shared workstation. That gives the user a recent mental baseline.

For people using ChatGPT, Codex and the API across several devices, account security has become a small identity estate. Security history adds visibility to that estate. Its strongest contribution is not a green assurance badge. It is a record that can contradict an assumption.

Key facts