Open-source account takeover detection

October 16, 2025 · 4 min read

Account takeover happens when someone gains unauthorized access to another person's online account, usually through stolen or guessed credentials. Once inside, the attacker changes login details to lock the original owner out, then harvests payment data, loyalty points, or personal information, or uses the compromised account as a stepping stone to reach others.

Any product with user accounts is a target. What separates account takeover from a data breach is that it is active. The attacker operates inside your product, sometimes for days or weeks before anyone notices.

Account protection is the one security function that should never be outsourced. The reasons go beyond data sovereignty, though that matters too. They are operational, and they become obvious the first time something goes wrong with your SasS vendor.

The vendor is a single point of failure for your product

Imagine your account protection vendor deploys a new AI-generated detection model on a Tuesday afternoon. The model is more aggressive than the previous one. It starts flagging legitimate login attempts as suspicious. Returning users who have logged in the same way for years are suddenly blocked or challenged.

Your support queue fills up. Users cannot access their accounts. Your team investigates and finds nothing wrong on your side, because nothing is wrong on your side. The problem is in the vendor's model, running on the vendor's infrastructure, updated on the vendor's schedule. Your developers cannot inspect the logic, cannot roll back the change, and cannot fix the problem. They only can file a support ticket and wait.

Meanwhile, every blocked login is a user who may not come back. Every false positive is a support ticket that costs staff time and customer trust. The vendor's update cycle broke your product, and you have no ability to respond except to ask them to fix it.

This is not a hypothetical edge case. Any system that makes real-time decisions about whether your users can access your product is a system that can break your product. When that system runs on someone else's infrastructure under someone else's control, you have accepted a dependency where the vendor's mistakes become your outage.

The vendor is also a breach target

Account protection systems hold detailed behavioral data about your users: login patterns, IP addresses, session histories, geographic locations, and the signals that distinguish each user from an attacker. This is precisely the information an attacker would want to study before launching a targeted campaign against your users.

When that data sits on a vendor's infrastructure, it is exposed to the vendor's security posture, their backup practices, their employee access controls, and their incident response capabilities. You cannot audit any of this in a meaningful way. You review their SOC 2 report, sign a data processing agreement, and hope.

The Okta breach demonstrated this risk clearly. Attackers gained access to Okta's support case management system, which contained session tokens and authentication data that customers had uploaded during troubleshooting. This allowed the attackers to view files uploaded by some Okta customers as part of recent support cases. Some of the affected customers are Cloudflare and BeyondTrust, which have since released their own reports about the effects on customers. The breach affected customers who relied on Okta for identity and access management, and the compromised data included exactly the kind of behavioral and authentication signals that account protection systems collect. The vendor's security failure became every customer's exposure.

Account protection data is at least as sensitive. Login behavior patterns, and geographic histories tied to authenticated users are a roadmap for attacking those users. Keeping that data on your own infrastructure, under your own security controls, is the only way to ensure it is protected to your standards.

How tirreno handles account takeover

tirreno is an open-source security framework that runs entirely on your infrastructure. Your backend sends login, session, and account change events to tirreno. The behavioral profiles, risk scores, and detection results stay in your database. There is no client-side script and nothing visible to users or attackers.

Every rule weight is configurable. Every rule is readable. When the detection produces a false positive, you open the user's profile, see which rules fired and with what weights, and adjust. When a new attack pattern appears, you write a rule. The cycle from identifying a problem to deploying a fix is hours, and the fix is yours to make. You are not waiting on a vendor's release schedule.

The auto-blacklisting threshold triggers automatic action for accounts that accumulate overwhelming risk signal. The manual review threshold surfaces accounts for investigation with full context. Your team makes decisions based on readable evidence, not an unexplained score from a system they cannot inspect.

Getting started

Install. Deploy a tirreno instance for your product. The administration guide covers setup and configuration.

Send login and account events. Send events to tirreno from your backend for logins (successful and failed), password changes, email changes, and session activity. Include user identifier, IP, user agent, timestamp, and event type. The developer guide has the API schema.

Apply the account_takeover preset. Open the rules page, activate the preset, and browse the activity page. Look for accounts with login anomalies, device changes preceding account modifications, and credential stuffing patterns in your authentication failure rates.

Tune for your users. Adjust rule weights based on your actual user population. A product with many mobile users will have different device-change norms than a desktop SaaS application. A product with a global user base will have different geographic expectations than a regional one. The rules are yours to configure.

Download at tirreno.com/download. A live demo is at play.tirreno.com.