An exchange account can be exposed even when no withdrawal has occurred. A forgotten browser session, an old API key, a reused email password, or a phone number takeover may provide a path to future loss. A session audit creates an inventory and removes unnecessary access. It should be performed from the official domain, on a trusted device, and recorded without copying secrets into the report.
Secure the starting point
Use a known device, updated browser, unique password, and strong second factor. Type the exchange domain or use a saved bookmark rather than a search advertisement. Check the account’s contracting entity and region before changing settings, because different entities can expose different controls. If the account shows an unfamiliar recovery email or phone, capture evidence and contact official support before deleting records.
Review active sessions
List browser, mobile, and API sessions with last-seen time, approximate location, and device label. Revoke entries you cannot identify, then change the password if there is any doubt. A location can be imprecise, so treat it as a clue rather than proof. Save a redacted audit date and session count; do not paste session tokens or cookies into a document.
Inventory API permissions
For each key, record purpose, owner, creation date, source IP, and permissions. Disable keys with trading or withdrawal capability when a report does not need them. Review IP allowlists and expiration settings. A key that has never been used is still a credential. Export only public metadata and verify that the exchange’s API page reflects the revocation.
Inspect withdrawal controls
Check address allowlists, cooldowns, email confirmations, device approvals, and withdrawal limits. A whitelist can reduce destination risk but may delay an emergency, so document who can change it. Verify that the notification email and mobile alerts go to controlled accounts. Never “test” a control by sending funds to a personal address supplied by a support agent.
Check recovery and identity exposure
Review password-reset methods, authenticator devices, backup codes, and identity documents stored by the platform. Remove obsolete devices and regenerate backup codes through the official flow. Keep a note of the date and the minimum information support needs. A recovery contact should not request a seed phrase, private key, or full one-time code.
Respond to an anomaly
If you find an unknown session, key, or withdrawal address, freeze activity using the platform’s documented security control, revoke credentials, and contact official support. Check recent deposits, withdrawals, orders, and account emails for changes. Preserve transaction ids and timestamps. Do not confront a suspected attacker through a reply address in an email; use the logged-in security center.
Schedule the next review
Set a calendar interval based on account value and activity, and repeat after a phone, email, staff, or device change. A short checklist is more likely to be used than a long policy. Record the before-and-after access inventory so a future reviewer can see which controls changed and why.
Worked example: an unknown API key
An account audit finds a key created six months ago from an IP that no longer belongs to the reporting server. First preserve the key id, permission labels, and last-use time, then revoke it through the official security center. Review orders, withdrawals, email changes, and active sessions around the last-use timestamp. Rotate the account password and second-factor recovery codes from a clean device. The incident note should distinguish evidence of access from evidence of a completed transfer; an unfamiliar key alone does not prove funds moved.
Operational handoff
For a family or small team, assign one person to read the inventory and another to confirm revocations from a separate device. That separation catches an audit that merely records settings without changing them. Preserve a before screenshot with names and balances redacted, then record the after state and notification received. When the exchange does not provide a clear session history, note the limitation and rely on password, second factor, API, and withdrawal evidence instead of guessing.
Frequently asked question
Is a successful login proof that an exchange account is secure?
No. Security also depends on active sessions, API permissions, withdrawal destinations, recovery methods, and notifications. A login check is only one line in the audit.