The homepage is about the person. This page is about the mechanism.
Guardian has two layers. The first decides whether a remote connection is allowed to exist at all. The second watches what happens inside the ones that are.
The threat model
In a remote-support scam the attacker ends up holding two things at the same time: control of the machine, and the attention of the person using it. Almost every consumer security control assumes at most one of those. A prompt on the screen fails because they have the screen. A warning the user must heed fails because they have the user.
So the only durable control is one whose approval step sits outside both. That is the single idea the rest of this page is built on.
Layer one: nothing connects without an approval
Guardian's default answer to a new remote connection is no. A session is held, not established, until an approval arrives. Who may give that approval is configured on this website, and there are two configurations:
- A second person. Guardian emails a named approver a request carrying the address, the remote tool, and the time, and shows the same request in the dashboard. They allow that one connection, whitelist the address, or refuse. The attacker holds the victim's machine and the victim's attention; neither gives any route to a different person. This configuration is outside the attacker's reach by construction, and it is the default.
- The owner, for their own PC. Either by approval link or by PIN. Both are bounded by the same fact: the approver is the person the caller is speaking to.
Both fail closed. No approval, a wrong PIN, or an expired hold all end the same way: the session is dropped before control changes hands.
Device binding on approval links
Email is delivered to an account, not to a device, so possession of a link is a poor authorisation test: the link is actionable from anywhere the mailbox is open, including the protected machine, where an attacker may already hold a signed-in session. Guardian therefore binds approval to a device rather than to possession of the link.
A device becomes an approving device once, by following an enrolment link and holding the credential it issues. The protected machine cannot be one. At the moment of approval Guardian checks whether the approving browser can reach the local agent of the machine the request is about, and refuses if it can. That test is a property of where the browser physically is rather than the network address it appears to come from, so a shared connection, NAT, or a VPN does not defeat it.
The effect is that somebody in control of the PC cannot approve their own inbound session, even with the owner's mailbox open in front of them.
What device binding does not solve
Binding removes the attacker's ability to approve on the owner's behalf. It does not change who the approver is. Where the protected PC belongs to the person being telephoned, self-approval still routes the decision to the one participant the attacker is actively working on, and no amount of device separation alters that.
Moving the approval to a second device does raise the cost. The request is rendered on a surface the attacker has no control over, showing the address and the tool — a materially better warning than a prompt on a screen they are driving, and a better circuit-breaker than a PIN. It is not a lock.
A second person is a lock, because there is no conversation in which they take part. We would rather state that than let a configuration choice quietly decide whether the product's central claim is true.
Why the setting lives on the website
If the approval mode could be changed from the PC, it would be worth nothing the moment somebody was controlling the PC. So the mode, the PIN, the whitelist, and the Blocked IPs list are account state on this site, not local state on the machine.
Repeated failures are terminal
Guardian counts dropped connections per address. Five failures move that address to Blocked IPs, where it is refused without generating another prompt or another email. The list is visible and editable in the dashboard, so an address blocked by accident can be released.
Layer two: an approved session is still a watched session
Approval is a door, not a blank cheque. Inside an allowed session, Guardian still looks at what happens: whether installers are transferred, whether privileges escalate, whether the activity stops resembling the support that was agreed to. Those events count together, and Guardian can end a session that turns.
This is where behaviour matters rather than brand names. A scammer can move from one well-known remote tool to an obscure one; a list of product names would miss that. What does not change is the shape of the activity.
What a person actually sees
Approval requests and incidents are written as sentences, not alert codes: who asked to connect, from where, what was decided, and what followed. Guardian Story carries that plain version, with the technical view of the same event one step underneath.