Jaguar Land Rover reportedly brought more than 30,000 employees onsite to reset their passwords after its cyberattack. That may have been necessary cleanup. But let’s be honest about what it was. Security theater.
JLR was reportedly hit by a group linked to Scattered Spider. And Scattered Spider does not need yesterday’s password to come back tomorrow. Its documented playbook is built around social engineering employees and IT help desks into resetting passwords, replacing MFA factors, enrolling new devices, and granting access to accounts they should never control.
So what exactly does forcing 30,000 people to choose new passwords accomplish? It invalidates old passwords. That is all.
It does not stop a criminal from calling the help desk an hour later and claiming their phone was lost. It does not stop a criminal from using stolen personal data to sound exactly like an employee. It does not stop a fake login page from capturing the newly changed password. It does not stop a push notification from being approved. It does not stop an authenticator code from being relayed in real time. It does not stop a support agent from resetting the account again. And it certainly does not prove that the person logging in is actually the employee they claim to be.
That is the central problem: Passwords are not identity.
A password is a secret that can be stolen, phished, reset, guessed, reused, relayed, or simply handed to an attacker by a person under pressure. Scattered Spider knows this. ShinyHunters knows this. Every criminal group using vishing, phishing kits, MFA fatigue, help desk manipulation, or session relay attacks knows this.
They are not trying to defeat your password policy. They are exploiting the fact that your organization still believes a password, a push approval, or a help desk conversation is enough proof of identity. It is not.
After a breach, organizations should invalidate exposed passwords, revoke suspicious sessions, remove unauthorized MFA factors, investigate privileged account activity, and review every recovery action that occurred around the incident. That is basic containment. But it is not prevention.
The prevention question is simpler: Could the same attacker use a convincing phone call, phishing page, help desk escalation, or MFA relay to get access again? If the answer is yes, then the company has not fixed the problem. It has simply reset the clock.
A company cannot train its way out of this. Not when attackers can use AI to generate perfect phishing pages, cloned voices, tailored emails, and detailed employee impersonation scripts in minutes. The employee is no longer the right place to put the final security decision. The architecture has to make the decision.
The real response after an attack like this is not “everyone choose a stronger password.” It is to remove passwords from the equation. No passwords to steal. No codes to relay. No push prompts to approve. No mobile authenticator enrollment that can be socially engineered through a help desk workflow. No recovery process where the attacker merely needs to sound convincing enough. This is where biometric assured identity changes the entire model.
With Token products, authentication requires a live fingerprint match on secure hardware. The authentication credential is cryptographically bound to the legitimate site or application. The device is physically present with the authorized user.
The attacker can know the employee’s name. They can know the employee’s password. They can know the employee’s address, title, mobile number, manager, department, and recent travel schedule. They can call the help desk sounding completely convincing. They still cannot authenticate.
No registered Token device. No live fingerprint. No access. A fake phishing site cannot use the credential because the authentication is bound to the real domain. A real time relay attack cannot simply capture and reuse a one time code because there is no code. An attacker cannot pressure an employee into approving a push notification because there is no push notification. And an attacker cannot call the help desk and have a new fingerprint issued to their hand.
That is the point: The system should not be asking, “Does this person know the password?” It should be asking, “Is this physically the authorized person, using the authorized device, at the legitimate application? That is biometric assured identity.
JLR’s password reset may have looked decisive. It may have been operationally difficult. It may have reassured the board, employees, customers, and regulators that something urgent was happening. But it did not close the attack path used by the very people who allegedly attacked JLR.
The same attacker could have returned immediately. The same vishing call could have worked. The same fraudulent password reset could have worked. The same MFA manipulation could have worked. The same phishing relay could have worked.
That is not recovery but a temporary pause before the next incident. The companies that will avoid becoming the next JLR are not the ones that reset passwords faster. They are the ones that eliminate passwords entirely and move to phishing resistant, hardware based biometric identity.
Thousands of Token users already operate this way. No Token. No fingerprint. No legitimate domain. No entry.