Read the request
Example: “Maya from Finance wants the Payroll Dashboard from a managed iPhone in London using a Face ID passkey.” Consistent evidence suggests it may really be Maya.

READ THE LOGIN. JUDGE THE RISK. PROTECT THE VAULT.
NOW PLAYING: “ZERO TRUST AFTER MIDNIGHT” - ORIGINAL CYBER-HOUSE MIX · MOVE A / D OR ← / → · APPROVE J · QUARANTINE K · MFA L
You are not collecting colours. Each incoming card represents a person trying to open a company application. Move beneath a card and the case-file panel shows the employee, requested system, device, location, authentication method and risk evidence. Make the decision before that login reaches the Identity Vault.
Example: “Maya from Finance wants the Payroll Dashboard from a managed iPhone in London using a Face ID passkey.” Consistent evidence suggests it may really be Maya.
Press Approve only when the person, device, location, role and authentication evidence make sense together. The request is allowed into the protected application.
Press Quarantine when evidence suggests account takeover: impossible travel, an unknown device, denied MFA, a stolen session or an unusual request for administrator access.
When its meter reaches 100%, MFA Pulse asks every active login for stronger proof. Legitimate users complete the check; simulated impostors fail and are removed.
Passwords can be guessed, phished, reused or stolen. Identity security asks a wider question: does this login behave like the real account owner? Identity Grid turns device trust, location, authentication, requested privilege and session behaviour into visible evidence. The goal is to recognise a normal sign-in, challenge uncertainty and stop a convincing impostor without locking out legitimate people.
Hover, focus or tap any control card to reveal a real-world identity-security example.
MFA is the extra proof requested by many phones, email accounts, workplaces, banks and social platforms. Product screens differ, but the security principle is the same: a stolen password should not be enough to enter.
When an Apple Account signs in on a new device, Apple can require the password plus a six-digit code displayed on a trusted device or sent to a trusted phone number. On supported Apple devices, Face ID or Touch ID can authorise use of a passkey stored in iCloud Keychain.
Apple passkey security guidance →Google 2-Step Verification may ask you to tap a prompt on your phone after entering a password. A Google passkey can instead use your fingerprint, face scan or screen-lock PIN to prove that you possess and can unlock the registered device.
Google 2-Step Verification guidance →A Microsoft work, school or personal account may send an Authenticator notification to a registered phone. The user reviews and approves the sign-in, or enters a one-time code. Microsoft also supports passwordless sign-in using the app.
Microsoft Authenticator guidance →An attacker who already knows a password may trigger repeated phone prompts, hoping the tired or confused user eventually taps Approve. An unexpected prompt should be denied. In Identity Grid, repeated prompts appear as “push spam” and should be quarantined.
Passkeys and FIDO security keys use cryptographic proof tied to the legitimate website. They are designed to resist fake sign-in pages because there is no reusable password or code for a person to reveal to the attacker.
CISA phishing-resistant MFA guidance →MFA reduces risk, but defenders still monitor sessions. Malware, unsafe recovery processes and stolen session tokens may let an attacker act after authentication. That is why the game also checks devices, locations, roles and session behaviour.
Identity Threat Detection and Response (ITDR) is the work of finding and responding to attacks that misuse user accounts, administrator identities, service accounts, authentication systems or active sessions. It connects prevention with investigation: use strong authentication and least privilege first, then watch for behaviour that suggests a trusted identity is no longer under its owner’s control.
A suspicious login detection system may compare a request with previous behaviour. A familiar managed laptop during normal working hours is different from an unknown browser attempting a payroll export at 2:14 a.m. from a new country. One unusual signal should not automatically prove guilt; several related signals create a clearer reason to allow, challenge or block the request.
In a real incident, quarantining an account can involve revoking sessions, disabling access temporarily, resetting credentials, checking the device for compromise and reviewing audit logs. The purpose is containment: stop further harm while the security team establishes what happened.
Multi-factor authentication asks for more than one kind of proof before granting access. A service might combine something you know, such as a password, with something you have, such as a trusted phone or security key, or something you are, such as a fingerprint used to unlock a device-bound credential.
Two-factor authentication, or 2FA, uses exactly two factors. MFA is the broader term and can use two or more factors. In everyday product language the terms are often used for the same extra sign-in step.
Deny it. Do not approve a sign-in you did not start and never share a verification code. Then review recent account activity, change a potentially exposed password and report the event through your organisation’s security process.
In this game, Quarantine means blocking the suspicious login before it reaches protected data. In a real organisation, responders may disable an account temporarily, revoke active sessions, require a password reset, isolate a device and investigate the related activity.
Not automatically. Face ID or a fingerprint commonly unlocks a phone or authorises use of a passkey stored on that device. Whether the complete sign-in counts as MFA depends on how the service combines possession of the device, biometric verification and any other factor.
It is a change from the user’s normal pattern, so it raises risk, but it is not proof of an attack by itself. Good identity systems combine several signals - device trust, location, time, requested privilege and authentication result - before allowing, challenging or blocking access.
SENTINEL-9 represents the analyst protecting access. The Mimic represents cloned credentials, forged devices and stolen sessions. The arcade visuals are fictional; the identity-security decisions underneath them mirror real defensive questions.
SENTINEL-9PLAYER // TRUST ENGINE
THE MIMICFINAL THREAT // CLONED ID