A password works from any machine that can reach the login page. Once it has been phished, guessed or leaked, nothing in the password itself tells the system who is typing it. A device is different, because it sits on a particular desk or in a particular bag. Tanflow Device Trust, part of the Tanflow IAM Suite, uses that difference to tie an account to one machine the organisation has approved.
Why a stolen password travels so easily
Most breaches still start with a stolen credential, one that someone else now holds. A phishing page collects it, a reused password turns up in a breach dump, or a user writes it on a note. The attacker can then try it from their own laptop, in another city, at any hour. A check that only asks what the user knows cannot tell the real user apart from the person who copied the secret.
Multi-factor authentication narrows that gap by asking for a second factor. Device Trust asks a different question: did this sign-in come from the machine registered to this user?
How the binding is set up
Tanflow installs a lightweight utility on the user's device, and the utility registers that machine as the user's one trusted device. It is a small Tanflow utility. It is not a heavy agent, and it needs no ongoing maintenance once it is in place.
Administrators control the binding. They enrol a user's device, and they can later re-bind it or release it. Since the binding is administrator controlled, each account ends up tied to hardware the organisation has approved.
What happens when the password is used on another machine
Once a device is bound, the account can authenticate only from that device. A sign-in from any other machine is refused, even when the username and password are correct.
Take an illustrative case. Someone in a finance team types their password into a convincing fake login page. The attacker now has a working password and tries it from their own laptop. Tanflow refuses the sign-in, because that laptop is not the device registered to the account. The attempt is recorded, which tells the security team that the password is in someone else's hands and should be changed.
Every bound device is recorded too. A security reviewer can see which machine each user is tied to, along with each attempt that came from a different one.
Replacing or losing a device
Laptops get replaced, break and go missing. When that happens, an administrator releases the old binding and enrols the new device, so the user stays bound to their current, approved hardware. After the release, the old machine is no longer the trusted device for that account.
A lost laptop deserves prompt attention for this reason. Until the binding is released, it remains the one machine the account will accept.
How Device Trust sits alongside MFA and SSO
Device Trust works with the other sign-in controls in the IAM Suite as an extra check. Tanflow MFA asks for a second factor, which can be a TOTP code from an authenticator app, an email or SMS one-time code, or a FIDO2 security key or passkey. Tanflow SSO then gives the user one session across the applications federated with it. Device Trust adds a condition on the hardware the sign-in comes from.
Each check stops a stolen password for its own reason. MFA stops it when the attacker lacks the second factor. Device Trust stops it when the attacker is not on the bound machine. With both in use, an attacker would have to hold the password and the factor while sitting at the registered device.
Which accounts to bind first
Tanflow describes Device Trust as a simple, strong control for high-sensitivity roles and shared environments. A sensible starting point is the set of accounts whose misuse would do the most damage, such as people who approve payments or who administer identity itself. The IAM Suite runs on the organisation's own servers or private cloud, so the device bindings and the record of blocked attempts stay inside its perimeter with the rest of its identity data.