An unexpected verification code, unfamiliar device, or password warning can leave you asking whether someone actually accessed your account. The useful next step is to establish what happened, which access paths are affected, and which evidence is still missing. Different signals answer different questions.
Quick answer
Check three layers: known credential exposure, activity recorded by the account provider, and settings that could preserve unauthorized access. Review sign-ins, devices, recovery methods, connected apps, and email rules. Krypt helps examine stored passwords and organize secure replacements and recovery records. Only the provider can show its account activity; a clean password scan cannot prove that nobody accessed your account.
Separate exposure from account access
A service breach, an exposed password, and an account takeover are related but distinct events. A breach can disclose an email address without disclosing its password. The same password value can appear in a dataset because another person chose it. Conversely, an intruder can access an account through a stolen session or permission grant even when its password is unique.
Use this evidence table to keep the investigation focused. It is a practical framework for comparing signals, rather than a scoring system that declares an account safe.
| Layer | Evidence to inspect | What it establishes |
|---|---|---|
| Exposure | Breach notices, email exposure, matched passwords, reuse | A reason to replace credentials or investigate; not proof of account access |
| Account activity | Successful sign-ins, unfamiliar devices, messages, security changes | Events at this provider that can be compared with your own actions |
| Persistent access | Sessions, app permissions, recovery changes, app passwords, forwarding | Access paths requiring separate review and possible revocation |
1. Start from a trusted account page
Open the provider's app or navigate to its known website yourself. Do not use a password-reset link supplied by an alarming message until its origin is established. A convincing warning can itself be the entry point for credential theft. Never give a caller a verification code or approve a sign-in that you did not initiate.
Record the account identifier, the trigger for concern, the time and time zone, and what you observed. Keep observations separate from conclusions: “successful sign-in from an unfamiliar browser” is evidence; “my neighbor hacked me” is an unsupported attribution. You can preserve a screenshot of the event without recording passwords, session cookies, or one-time codes.
If access is being lost or unauthorized changes are continuing, follow the provider's recovery process immediately. Evidence gathering should support containment, not delay it. For a work or school account, contact the organization's administrator because the administrator may have access to more complete logs and revocation controls.
2. Read sign-in activity in context
Expand suspicious events and compare their time, device, browser, access method, and outcome with your actual activity. A rejected password attempt is different from a successful login. A recognizable laptop name does not settle the question either: names are labels, and an existing session may already have access.
For Google accounts, review recent security events and devices, then inspect changes to recovery details and verification methods. Also check Gmail settings and sharing activity if the symptoms involve messages or files. Google's compromised-account guide identifies these review areas and the provider's response controls.
For Apple accounts, investigate verification codes you did not request, unfamiliar trusted devices, changed account details, unexpected purchases, or a password that no longer works. Review the device list and confirm you control the associated phone numbers and email addresses. Use Apple's account-compromise guidance for the current recovery route.
Microsoft's Recent activity documentation distinguishes incorrect-password attempts, successful sign-ins, automatic synchronization, and security changes. It describes a 30-day view of significant events rather than a complete access log. It also warns that mobile routing can produce an unexpected location. Treat location as supporting context, not a physical address or identity.
For example, an unfamiliar city at the exact time you used your phone deserves a different interpretation from a successful login while you were asleep followed by a changed recovery address. The second combination provides stronger evidence because the events reinforce one another. Do not invent a numerical probability from a dashboard that does not provide one.
3. Check how access could survive
Authentication establishes access; sessions and delegated permissions can carry that access forward. This is why a password-change confirmation is only one part of an investigation. Review the provider's available controls for active sessions, remembered devices, recovery methods, app passwords, and connected applications. Their names and behavior vary by service.
An OAuth permission grant can allow an application to read particular data or perform particular actions. Inspect both the app's identity and its permissions. An app you recognize may have broader access than you expected; an unfamiliar app with mailbox access deserves prompt investigation. Google's linked-app guidance separates sign-in links from access to account data and explains how to remove that access. Revocation does not retrieve information already copied elsewhere.
For email, inspect forwarding destinations, filters, delegation, sent mail, and deleted items. An inbox can appear normal while a rule copies messages elsewhere or hides security notices. The FTC's recovery guidance includes forwarding-rule review, checking sent and deleted folders, reviewing recovery information, and signing out other devices.
Include recovery channels in the same review. A strong replacement password provides little reassurance if an unfamiliar recovery address can reset it. Review enrolled authentication methods individually and retain a legitimate way back in before removing old methods. If you find changes you did not authorize, use the provider's security process rather than assuming a password manager can reverse them.
4. Check exposure without confusing the result
An email-address breach lookup asks whether an address appears in known incident data. A password lookup asks whether a password value appears in a password corpus. HIBP documents these as separate services. Neither is a live view into your mailbox or a complete history of access to an account. See the Have I Been Pwned API documentation for the distinction.
A Pwned Passwords match includes the value's occurrence count in the dataset. That number is not the number of breaches of your account, sites where you used it, or successful attacker logins. Replace an exposed password anywhere you use it, even if the scan cannot identify where exposure occurred. A missing match has a narrower meaning: the checked dataset did not supply that match.
Krypt's private breached-password checking article explains the lookup mechanism in depth. This guide addresses the larger diagnostic question: what does that result mean alongside the provider's own evidence? A password warning is a useful lead. It does not replace the sign-in, recovery, and permission checks above.
Krypt's answer: a private place to assess and replace credentials
Krypt is a zero-knowledge password manager that brings the credential side of this workflow together in an encrypted local vault. Its password-health service identifies exact password reuse, flags empty or short passwords, lists records not updated in a year, and can check stored password values against Pwned Passwords. Those categories help you decide which records need attention while you investigate the actual accounts.
Interpret each category according to its scope. The current weak-password check uses a simple length threshold: an eight-character password passing that check is not a strength certification. An “old” record reflects its update timestamp, not evidence of theft. Neither label proves compromise. A duplicated password, however, identifies additional records to review when one credential is exposed.
During a breach check, Krypt computes SHA-1 hashes locally, groups their first five hexadecimal characters, requests matching ranges, and compares returned values on the device. This scan sends a hash prefix rather than your plaintext password or account identity. Network access is required for these range requests; the local vault and offline health categories do not turn the lookup into an offline service.
Current scan limitation: individual failed requests and non-success responses can leave entries absent from the returned result. The current interface can interpret those missing entries as zero matches, so an incomplete scan may look clean. If connectivity was uncertain, repeat the check on a working connection. Even a completed scan with no matches does not prove an account is safe.
When a credential needs replacement, use Krypt's generator to create a unique value, change it on the provider's genuine account page, and save the replacement against the correct record. Verify that the provider accepted it before treating the job as finished. Updating only the vault entry does not change the remote account password.
Krypt also lets you keep account notes and recovery codes with the relevant password record. A concise incident note can record which provider settings were reviewed, when a replacement was accepted, whether other sessions were revoked, and what follow-up remains. Record status and context, not authentication cookies or copied browser sessions. Keep vault recovery material accessible through your separate recovery plan.
What Krypt cannot tell you
Krypt does not inspect external account logs, identify who is signed in, detect email forwarding, or remove OAuth permissions. It does not continuously monitor email addresses or the dark web. Its local vault activity is not evidence about activity at Google, Apple, Microsoft, or another provider. Keep those two sources of information distinct.
It also cannot certify a device free of malware. If suspicious activity returns after account cleanup, investigate the device and its software through appropriate platform tools. Repeating password changes from an untrusted environment may leave the underlying access path unresolved. For confirmed compromise, continue with the provider's recovery process and Krypt's first-15-minutes breach-response checklist.
Turn the evidence into a decision
Consider an account with a password-exposure match but no unfamiliar provider events. Your record should say the credential needs replacement and that the reviewed activity did not establish takeover. Now consider an account with no password match but an unauthorized recovery-address change. The provider evidence warrants action regardless of the scan. These cases show why one green indicator should never cancel a stronger warning elsewhere.
For ambiguous findings, write down what would resolve them: confirmation that a device is yours, an explanation for a timestamp, or the provider's response to an unfamiliar event. Keep the original observation and the later resolution together. This makes a follow-up review useful instead of repeating the same checks without remembering what changed.
A practical account-review checklist
- Open the provider directly and confirm which account you are reviewing.
- Record the triggering event and time; distinguish observed facts from your explanation.
- Inspect available sign-ins and devices, including each event's outcome.
- Check recovery addresses, phone numbers, and enrolled authentication methods.
- Review persistent access and mailbox settings using the provider's controls.
- Use Krypt to identify relevant reused or exposed stored passwords.
- Replace affected credentials at the provider and save verified replacements.
- Document what remains uncertain and follow the provider's instructions if activity recurs.
A useful stopping point is a documented assessment: the available events were reviewed, unexpected access was addressed, vulnerable credentials were replaced, and remaining gaps are known. “No evidence found in these checks” is a defensible observation. “Nothing could have happened” goes beyond what a password scan or consumer account dashboard can establish.
FAQ
Does a breached password mean someone accessed my account?
No. A password match shows that the same password value appears in the checked exposure dataset. It does not identify your account or prove a successful sign-in. Replace that password wherever you use it, then inspect the affected providers for unauthorized activity.
Can my account be compromised if its password is not in a breach?
Yes. A stolen session, malicious app permission, phishing attempt, or compromised device can give someone access without a match in a public password dataset. Provider activity and recovery settings still need review, even when a password scan reports no matches.
Can Krypt tell me who is signed in to my email account?
No. Krypt checks stored password health and can screen password values against Pwned Passwords. It does not inspect your email provider's sessions, devices, forwarding rules, or account logs, and it does not continuously monitor email addresses or the dark web.
Is changing my password enough to remove an attacker?
Do not assume so. Follow the provider's recovery process and review active sessions, connected apps, recovery methods, app passwords, and email rules. Revoke access you did not authorize and check device security; the effect of a password change on existing access depends on the service.
Technical references
The primary references linked above cover distinct evidence sources: HIBP's exposure data, Google's and Apple's account checks, Microsoft's event meanings, Google's app-permission controls, and the FTC's recovery guidance. Together they support the investigation; none turns a password-health result into an account-access verdict.
Use Krypt to review stored password health, create unique replacements, and keep your account recovery records organized in an encrypted vault.
