Identity protection
Password exposure checks, account sign-in safety and hacked-account help today; verified-address monitoring interfaces need a configured provider for results.
- Available
- 03
- Limited
- 01
- Not released
- 03
- Coming
- 01
How the attack works
Most account takeovers do not need a new vulnerability. Passwords leaked from one site are tried on others (credential stuffing), common passwords are tried against many accounts (spraying), and exposed login services are guessed at continuously (brute force).
- STAGE 01
Collection
Breach dumps, infostealer logs and phishing pages produce lists of usernames and passwords.
- STAGE 02
Automation
Tools try those pairs, or common passwords, against login pages, SSH and remote-desktop services.
- STAGE 03
Takeover
One reused password is enough. Sessions, recovery email and two-step settings are changed.
- STAGE 04
Use
The account is used to send scams, steal data, or as a foothold for the next step.
- People who reuse passwords
- Servers with SSH password login open to the internet
- Small business admin accounts without two-step verification
A common pattern: a server exposed to the internet sees a continuous background of failed SSH logins from many addresses, trying usernames like root, admin and service names. Any account with a weak password is eventually found.
Stolen passwords from someone else's breach are reused against your accounts. On servers, the same problem shows up as password guessing over SSH.
Sensor, rule, evidence, action
Each step carries its own state. A step that is not built is shown as coming, not skipped.
SSH authentication log
The server collector reads failed and accepted SSH logins from auth.log or /var/log/secure.
AvailableServer agent (Linux)BIDUA-HUB-0001 brute force
5 failures from one address in 300 seconds raises a level-10 incident (ATT&CK T1110.001, T1110.003). Tested. The only family the register marks detected.
AvailableHub, productionAddress, count and window
The incident is stamped with the rule id, version and level, and linked to the events that raised it.
AvailableAlert; ban is manual
An incident appears on the console. Blocking the address is a manual administrator action.
Available
Password checks use k-anonymity: the password is hashed on your device and only the first five characters of the hash are sent. The password itself never leaves.
For servers, repeated failed logins from one address raise an incident (5 failures in 5 minutes).
What works today, and what is coming
What works today
04In production or in the current download.
- SSH brute-force detectionAvailable
The one attack family our register marks as detected, with a tested rule.
Server agent (Linux), SMB, Enterprise XDR
- Password exposure checkAvailable
k-anonymity lookup; the password never leaves the device.
Android app 4.50
- Two-step sign-in, passkeys and session reviewAvailable
For the Safeavio Sentinel account: authenticator-style second step, passkeys, sign out everywhere and rotate agent keys.
Web portal, Android app
- My e-mails and numbersLimited
A list you keep on the phone of the addresses and numbers you want to watch.
Android app 4.50
Built, not yet released
03The code exists and is tested in the repository; it has not shipped to users.
- E-mail breach lookupNot released
Built for addresses you consented to and confirmed with an e-mailed code. A configured breach provider is required for results. Mail verification alone is not a breach check.
Web portal, Android app
- Verified-email monitoring schedulesNot released
Opt-in provider interface and schedules are implemented. Automated checks and notices need a configured provider.
- Breach and credential-monitoring interfacesNot released
Verified-address, opt-in provider interfaces and schedules are implemented. Automated exposure results need a configured provider. Without one the result is Needs a provider, never clear.
Coming
01Not built yet. Nothing on this list runs today.
- Family identity monitoringComing
One view of every member's exposure.
7 attack families map to this capability
Copied row by row from our engineering register. A family counts as detected only when a rule, a sensor that feeds it and a test that makes it fire all exist.
Feature states above and register statuses measure different things: a feature can be built while the family it addresses stays unobserved, because the register counts sensors and rules, not screens.
| # | Attack family | Status | What the register says |
|---|---|---|---|
| 024 | Password Spraying / Brute Force | Detected | Sensor, rule and test all exist: SSH failures from the server collector, 5 from one address in 5 minutes raises an incident. Per-address only; the collector can re-send old lines, which re-raises stale incidents.Runs in production |
| 023 | Credential Stuffing | Partial | Covered only where it looks like brute force: 5 failures from one address in 5 minutes. Stuffing spread across many addresses is not grouped; console login failures do not reach correlation.Runs in production |
| 056 | Credential Dumping | Partial | Linux server agent 3.20 checks, periodically and not in real time, for credential-tool names, unusual /etc/shadow handles, private keys in temporary or web folders and unsafe permissions on .env and key files (rule BE-13). File reads are not audited. No Windows LSASS or macOS keychain telemetry. Not yet run on a real Linux host.Runs in production |
| 022 | Broken Authentication | No sensor | Design flaws are not visible from login outcomes, and the console audit log is not fed to correlation. Only preventive controls exist.Nothing runs |
| 026 | Session Hijacking | No sensor | No session-context anomaly detection; token revocation on logout is preventive onlyNothing runs |
| 050 | Credential Theft / Infostealer | No sensor | No credential-store access telemetry. A breach lookup shows exposure, not theft.Nothing runs |
| 099 | SIM Swap | No sensor | No SIM-change telemetryNothing runs |
What runs where, and what never leaves
Classification happens on the device before anything is queued. Cloud reporting is off by default on consumer devices and turning it off also stops events already queued.
Runs on the device
- Your password, when you check it: it is hashed on the device and only the first five characters of the hash are sent (k-anonymity)
May reach the cloud
- From servers: SSH login events (address, user, outcome) to your console
- Email addresses you choose to look up in the portal
Never leaves
- Your password, in any form that could be reversed
- Contents of your accounts
Editions that include it
Local-first protection for your own computer and phone.
> One person, 1–3 devices
Provider interfaces for chosen-media checks and email exposure monitoring.
> Individuals who want the advanced checks
One summary for the whole household, without reading anyone's phone.
> Households with supported paired phones
One console for your servers, Android devices and alerts.
> Organisations with 5–250 devices
A shared timeline of security events across endpoints, servers and phones.
> Security teams and MSPs
Each feature above names the platform or edition it runs on. An edition's own page lists the full state of that edition.
What to do if…
Practical steps that work whether or not you use our products.
A breach lookup shows your email
- 1.Change the password for that service and anywhere you reused it.
- 2.Use a password manager so every site has a different password.
- 3.Turn on two-step verification, preferably an app or passkey rather than SMS.
Your server shows a brute-force incident
- 1.Check whether any login from that address succeeded.
- 2.Disable SSH password login and use keys only.
- 3.Block the address at the firewall, and consider limiting SSH to known addresses or a VPN.
You cannot sign in and recovery details changed
- 1.Use the provider's account-recovery process from its official site.
- 2.Tell your bank if the email is linked to banking.
- 3.After recovery, sign out of all sessions and review connected apps.
Limits and known gaps
- GAP-01Brute force is detected per source address only. Password spraying spread across many addresses is missed.
- GAP-02The collector re-sends recent log lines with the current time, so an old failure can re-raise an incident (a known false-positive source).
- GAP-03Credential stuffing is partial; console login failures do not reach correlation, and there is no failure-then-success detection.
- GAP-04Verified-address provider interfaces and opt-in monitoring schedules are implemented. Automated exposure checks require a configured provider; without one, the result is Needs a provider. Password-hash range checks are a separate service.
- GAP-05Infostealers, credential dumping, session hijacking and SIM swap are not observable. There is no MFA in the product yet.
Frequently asked
Do you send my password anywhere?
Which attack does Sentinel detect end to end?
Will it block the attacker's address automatically?
Capabilities that work alongside it
Checks a link before you open it and warns about lookalike domains.
Wi-Fi and connection awareness on phones; port-scan visibility and firewall control on servers.
A risk score built from real device signals: root, screen lock, encryption, risky apps.