Identity Is the New Security Perimeter
The 2023 MGM Resorts breach is the defining case study of identity-based attacks. The attackers — social engineering specialists who had never met MGM's systems — called the IT help desk, impersonated an employee using information scraped from LinkedIn, and convinced the operator to reset MFA credentials. From that single compromised identity, they owned MGM's enterprise environment within hours. Total disclosed losses: over $100 million.
This pattern repeats across the most significant breaches of 2023–2026. Okta — the identity provider — was compromised twice through social engineering targeting their support personnel. Microsoft Exchange suffered the Storm-0558 breach through forged authentication tokens. Colonial Pipeline, SolarWinds, and the Bangladesh Bank SWIFT heist all pivoted through compromised privileged identities.
The traditional network perimeter — the firewall as the security boundary — is strategically irrelevant. Cloud infrastructure, hybrid work, SaaS sprawl, contractor access, and supply chain integrations mean there is no meaningful "inside the network" anymore. Identity is the only perimeter that remains meaningful, and it must be defended accordingly.
The Evolution of Access Control Models
Role-Based Access Control (RBAC)
RBAC — still the dominant enterprise access control model — assigns permissions to roles rather than individuals. Users are assigned roles; roles have permissions. Administration scales: changing a "Finance Analyst" role affects every user in that role simultaneously. But RBAC fails at granularity: the Finance Analyst role that grants appropriate access 80% of the time creates overprivilege for the other 20%. That overprivilege is the attack surface that adversaries exploit.
The "least privilege problem" of RBAC: to reduce roles to truly minimal permissions, you need exponentially more roles. A typical enterprise with 200 business functions and 3 sensitivity levels needs 600 precisely-scoped roles — an administrative nightmare that in practice leads to broad, overprivileged roles.
Attribute-Based Access Control (ABAC)
ABAC solves RBAC's granularity problem by evaluating access decisions against multi-dimensional attribute policies:
ABAC Policy Example — Confidential Financial Data:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ALLOW IF:
user.department = "Finance" AND
user.clearance_level ≥ 3 AND
data.classification = "Confidential" AND
device.compliance_status = "Managed" AND
session.risk_score < 0.3 AND
time.current IN business_hours AND
location.country = "India"
DENY otherwiseABAC enables true least-privilege without role explosion, supports dynamic context evaluation, and integrates naturally with Zero Trust policy engines. The implementation complexity is the trade-off: attribute management, policy authoring, and policy testing require mature governance processes.
Zero Trust Architecture
Zero Trust is not a product — it is an architectural philosophy. Its core principle: never trust, always verify. Every access request is treated as potentially hostile regardless of network origin, evaluated against identity, device, context, and resource signals before access is granted, and continuously re-evaluated during the session.
Zero Trust Access Decision Engine:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Request arrives from: user@corp.com → Salesforce API
Policy Engine evaluates:
├── Identity: Authentication strength? MFA type? Session age?
├── Device: Managed? Patched? EDR active? Risk score?
├── Context: Time? Location? Impossible travel? Risk tier?
├── Resource: Sensitivity? Data classification? API scope?
└── Behaviour: Anomaly score? Access frequency? Volume?
Decision: ALLOW (with logging) | DENY | STEP-UP MFAPasswordless Authentication: Beyond the Password
Passwords are the original cybersecurity design failure. 80%+ of breaches involve compromised credentials (Verizon DBIR 2025). The root problem is not user behaviour — passwords are inherently phishable, reusable, and forgettable. The solution is eliminating them.
FIDO2 and WebAuthn
FIDO2 replaces passwords with public-key cryptography. During registration, a key pair is generated on the authenticator (hardware security key, device TPM, secure enclave). The private key never leaves the device. Authentication proves:
- Key possession: The private key is present
- User verification: Biometric or PIN confirmed locally
- Origin binding: The credential is bound to the specific domain — phishing sites cannot receive valid assertions
Phishing Resistance: Why FIDO2 Cannot Be Phished
The origin binding property is cryptographic. When Alice authenticates to google.com, her FIDO2 authenticator signs a challenge that includes google.com as the relying party ID. A phishing site at g00gle.com cannot receive a valid FIDO2 assertion for google.com — the authenticator verifies the origin before signing. Even if the phishing site is a perfect visual clone, the cryptographic binding prevents credential theft entirely.
MFA Security Comparison
| Authentication Method | Phishing Resistant | AiTM Resistant | Recommendation |
|---|---|---|---|
| Password only | No | No | ❌ Eliminate immediately |
| SMS OTP | No | No | ❌ SIM-swap vulnerable |
| Email OTP | No | No | ❌ Avoid |
| TOTP (Google Auth) | No | No | ⚠ Minimum baseline only |
| Push notification | No | Partial | ⚠ Add number matching |
| FIDO2 hardware key | Yes | Yes | ✅ Privileged accounts |
| Passkeys | Yes | Yes | ✅ All accounts |
| Certificate-based (PIV) | Yes | Yes | ✅ Enterprise preferred |
Identity Threat Detection & Response (ITDR)
ITDR addresses the gap between identity security controls (authentication, authorisation) and security operations (detection, response). It instruments the identity plane — IdP logs, directory service events, authentication telemetry — with ML-powered anomaly detection and real-time alerting.
Key ITDR detection scenarios:
- Impossible travel: User authenticates from Mumbai at 09:00, next authentication from London at 09:45
- Password spray: Many failed authentications across many usernames from the same IP/ASN
- MFA fatigue: Repeated push notifications to a user — indicates attacker attempting to exhaust the user into approving
- Privilege escalation: User granted Global Admin within minutes of initial authentication
- Lateral movement via service accounts: Service account authenticating to systems outside its normal access pattern
- OAuth consent abuse: New OAuth application granted broad scopes, especially Mail.Read or Files.ReadWrite
Just-in-Time Privileged Access
Standing privileged access — permanent admin accounts that exist 24/7 — is the primary driver of breach blast radius. Once compromised, a standing admin account gives attackers persistent, always-available access. JIT access eliminates standing privilege: administrators request elevated access on demand, provide business justification, receive time-bounded permissions (e.g., 2 hours), and permissions are automatically revoked at expiry.
Decentralised Identity: The Next Frontier
W3C Decentralised Identifiers (DIDs) and Verifiable Credentials (VCs) enable users to present cryptographically signed identity attributes without relying on a centralised identity provider. India's DEPA (Data Empowerment and Protection Architecture) and the EU's eIDAS 2.0 represent national-scale deployments of decentralised identity principles, giving citizens control over their identity data while enabling secure, privacy-preserving authentication to government and enterprise services.
Common Mistakes
- Accepting any form of MFA as "MFA complete": SMS OTP is bypassed trivially by AiTM and SIM swapping. FIDO2 is the only phishing-resistant standard.
- Neglecting service account identity: Service accounts, managed identities, and API keys are frequently overprivileged and unmonitored — primary targets for privilege escalation.
- No ITDR instrumentation: Deploying strong authentication without monitoring the identity plane for attack patterns creates a blind spot exactly where attackers pivot.
- Treating Zero Trust as a network project: Zero Trust is an identity project. Deploying micro-segmentation without addressing identity verification is architectural malpractice.
Expert Conclusion
Identity security is no longer a supporting discipline — it is the primary battleground of enterprise cybersecurity. The organisations winning this battle have eliminated passwords for privileged access, deployed FIDO2 for high-risk users, implemented JIT privilege for administrative functions, and instrumented their identity plane with ITDR. They treat every authentication event as a security signal to be evaluated, not a gate to be opened.
The organisations losing are those still treating IAM as a provisioning exercise rather than a security discipline — deploying identity solutions to enable access rather than to control it. The distinction in outcome, when attacks arrive, is measured in millions of dollars and months of recovery.
Frequently Asked Questions
Zero Trust is a security model that eliminates implicit trust based on network location. Every access request — regardless of whether it originates inside or outside the corporate network — is explicitly verified against identity, device health, context, and resource sensitivity signals before access is granted. It matters because the traditional network perimeter has dissolved: cloud, hybrid work, and supply chain access make "inside the network = trusted" an obsolete and dangerous assumption.
Role-Based Access Control (RBAC) grants permissions based on predefined roles (e.g., "Finance Analyst"). Attribute-Based Access Control (ABAC) grants permissions based on combinations of subject, object, and environmental attributes — enabling fine-grained policies like "allow access if: user.department=Finance AND data.sensitivity=Confidential AND device.managed=true AND time.is_business_hours". ABAC supports true least-privilege at a granularity impossible with role definitions.
FIDO2 is an authentication standard using public-key cryptography. A key pair is generated during credential registration; the private key never leaves the user's device. Authentication requires the user to prove presence (PIN or biometric) and sign a cryptographic challenge. Phishing resistance comes from the credential being bound to the specific origin (URL) of the legitimate site — a phishing site cannot receive a valid FIDO2 assertion for another domain.
Passkeys are FIDO2 multi-device credentials that sync across a user's devices via iCloud Keychain, Google Password Manager, or 1Password. They provide FIDO2-grade phishing resistance with user experience comparable to biometric unlock. They have replaced passwords for authentication at Apple, Google, Microsoft, GitHub, PayPal, and hundreds of other major services. Passkeys represent the practical end of passwords for consumer and enterprise authentication.
ITDR is the discipline of detecting and responding to identity-based attacks in real time. Unlike EDR (endpoint) or NDR (network), ITDR monitors the identity plane: authentication events, privilege escalations, impossible travel, OAuth consent abuse, service account anomalies, and lateral movement through identity federation. Leading ITDR capabilities include impossible travel detection, authentication spike analysis, and real-time session risk scoring.
Adversary-in-the-Middle (AiTM) attacks use reverse proxy tools (Evilginx2, Modlishka) positioned between the target and a legitimate service. The victim authenticates normally — including completing their OTP-based MFA — but the proxy captures both the credentials and the authenticated session token. The attacker replays this token to access the service. SMS OTP, email OTP, and TOTP are all vulnerable. Only phishing-resistant FIDO2/passkeys are immune.
Decentralised identity (DID) uses cryptographic proofs — W3C Verifiable Credentials — instead of centralised identity providers. Users present digitally signed credentials from trusted issuers (government, employer, university) directly to services, without those services querying a central directory. The user controls what attributes are shared and retains data sovereignty. Real-world deployments include India's DEPA framework and EU eIDAS 2.0.
Just-in-time access grants privileged permissions only for the duration required to complete a specific task, then automatically revokes them. Rather than maintaining standing administrative accounts (which create permanent risk), JIT systems require justification, approval, and time-bounded access elevation. Microsoft PIM, CyberArk, and BeyondTrust are common enterprise JIT implementations.
Authentication (AuthN) verifies identity: who is this person/system? Authorisation (AuthZ) determines permissions: what are they allowed to do? Modern security architectures separate these concerns strictly — authentication establishes identity claims (via OIDC/JWT), authorisation evaluates those claims against policy (via RBAC/ABAC engines). Conflating them in application code is a common OWASP A01 (Broken Access Control) vulnerability.
Priority order: (1) Deploy phishing-resistant MFA (FIDO2/passkeys) for all privileged accounts immediately. (2) Implement JIT access for all administrative functions — eliminate standing privilege. (3) Deploy an ITDR solution to detect identity-based attacks in real time. (4) Audit all service accounts and machine identities — these are frequently neglected and highly targeted. (5) Implement Zero Trust access policy with continuous re-evaluation, starting with the highest-risk application tier.
