Identity Is the New Perimeter (And It's Under Attack)

I've had more conversations about identity resilience in the past six months than in the previous five years combined. Something has shifted. Customers who used to treat Active Directory as "set it and forget it" infrastructure are now asking hard questions about recovery, integrity, and what happens when (not if) their identity systems get compromised.

That shift isn't paranoia. It's pattern recognition.

The Target Has Moved

For years, the security conversation centered on protecting data. Backup your files, replicate your databases, encrypt your storage. And those things still matter. But attackers have figured out something more elegant: why steal data when you can steal the keys to everything?

Identity systems, specifically Active Directory on-premises and Entra ID in the cloud, control who can access what. Compromise those, and you don't need to break into individual systems. You own the authentication layer itself. You can create accounts, elevate privileges, disable security controls, and move laterally without triggering the alerts that would catch traditional attacks.

This isn't theoretical. It's the playbook behind some of the most devastating breaches of the past few years. And it's why customers are finally asking the right questions.

Consider a few examples of what could happen:

A manufacturing company discovered that a service account with domain admin privileges had been compromised through a password spray attack. The attackers spent weeks exploring the environment undetected, eventually creating a Golden Ticket that gave them persistent, invisible access to every system in the forest. By the time the breach was detected, they'd exfiltrated intellectual property worth millions and left backdoor accounts scattered across multiple domains.

A financial services firm found malicious OAuth consent grants in their Entra ID tenant after an executive clicked a phishing link. The attacker gained delegated access to mailboxes and OneDrive across the organization, not by stealing passwords, but by tricking the identity system into granting legitimate permissions to a malicious app. The consent grant persisted even after passwords were reset because the problem wasn't compromised credentials; it was compromised authorization.

A healthcare organization suffered a hybrid attack where on-premises domain controllers were compromised through an unpatched vulnerability. The attackers modified group memberships and user attributes in AD, which then synced to Entra ID through Azure AD Connect. By the time the security team identified the breach, malicious changes had already propagated to the cloud, and they had no clean baseline to restore from.

These aren't isolated incidents. They're patterns.

The Foundation That Built Everything

Active Directory has been the backbone of enterprise identity for more than two decades. Since its introduction in 1999, AD has been the de facto standard for managing users, computers, and resources in Windows environments. It has governed authentication and authorization for entire organizations, controlled access to applications and file systems, and enabled centralized management at a scale that made modern enterprises possible.

For most of its existence, AD has been remarkably reliable. Object-level restores (recovering deleted users, groups, or organizational units) have been part of identity protection for years. The Active Directory Recycle Bin, tombstone reanimation, and authoritative restores became standard tools in every domain admin's toolkit.

But here's what hasn't been standard: full forest recovery.

While restoring individual objects is well-understood, recovering an entire Active Directory forest is a different challenge altogether. It's time-consuming, complex, and in many cases, fraught with failures. The interdependencies between domain controllers, global catalog servers, FSMO roles, trust relationships, and SYSVOL replication mean that a forest-level recovery isn't just technically demanding; it's something most organizations have never actually tested under realistic conditions. And when I say "tested," I don't mean in a lab with a handful of objects. I mean a production-scale forest with hundreds of thousands of objects, multiple domains, and years of accumulated configuration.

The uncomfortable truth? Most organizations that think they can recover AD in a crisis are operating on assumptions that have never been validated. And discovering those assumptions are wrong during an active incident is not the time you want to be learning.

The Hybrid Problem

Here's what makes this complicated: most organizations aren't purely on-premises or purely cloud anymore. They're running hybrid identity. Active Directory domains syncing to Entra ID. Users authenticating against both. Applications and resources spanning both environments.

That hybrid reality creates hybrid risk. A misconfiguration in AD can propagate to the cloud. A compromised Entra ID account can pivot back to on-premises resources. The attack surface isn't one system. It's the space between them.

And that space is where visibility tends to disappear.

I've sat in rooms where security teams can tell you exactly what's happening with their endpoint detection, their SIEM, their network monitoring. But when I ask about changes to AD groups or Entra ID application permissions, the answer is often silence. Not because they don't care, but because the tooling hasn't caught up to the threat model.

What Resilience Actually Means

When I talk about identity resilience with customers, I'm not just talking about backup and recovery. Those matter, but they're the last line of defense, not the strategy.

True resilience spans the entire lifecycle:

Hardening before the attack. Continuously monitoring for risky configurations, excessive privileges, dormant accounts with elevated access. The attack surface you don't know about is the one that gets exploited. This starts with foundational controls: enforcing multifactor authentication across all privileged accounts, implementing least privilege access, and leveraging microsegmentation to restrict lateral movement. Network segmentation limits what an attacker can reach even if they compromise credentials, containing the blast radius of a breach.

Detection during the attack. Identity Threat Detection and Response (ITDR) is becoming its own category for a reason. You need to see suspicious authentication patterns, privilege escalations, and directory changes in real time, not in a log review three weeks later. And here's the kicker: sophisticated attackers know how to disable security logging or inject changes directly into AD in ways that bypass traditional event capture. If your detection relies solely on Windows event logs, you're missing crucial indicators.

Recovery after the attack. This is where most organizations have the biggest gaps. You can restore AD from a backup, but how do you know that backup is clean? How do you validate that the restored state doesn't include the backdoor accounts or modified policies the attacker planted? Recovery without integrity verification is just restoring the compromise.

Learning from the attack. Every incident should feed back into better detection rules, tighter configurations, and updated runbooks. The organizations that recover well are the ones that treat every event as a forcing function for improvement.

The Entra ID Wake-Up Call

On-premises AD gets most of the attention because it's been around longer and the attack techniques are well-documented. But I'm seeing a shift in concern toward Entra ID, and for good reason.

Cloud identity is different. Changes happen faster. There's no domain controller you can physically isolate. And the scope of what needs protection goes far beyond what most organizations initially realize.

When people think about protecting Entra ID, they often think about users and groups. That's table stakes. But the attack surface is vastly larger:

Applications and service principals. App registrations and their associated service principals control how applications authenticate and what they can access. Compromise these, and attackers can impersonate legitimate applications to access data across your tenant.

Application permissions and consent grants. The permissions granted to applications, whether admin-consented or user-consented, determine what those apps can do on behalf of users. Malicious consent grants are a common persistence mechanism that organizations often miss during incident response.

Conditional access policies. These policies are your first line of defense for controlling authentication. Modify them, and attackers can bypass MFA requirements, remove location restrictions, or exclude their compromised accounts from security controls.

Administrative units and custom roles. Entra ID's delegated administration model means you're not just protecting global admin roles. Administrative units with scoped permissions and custom role definitions create a complex permissions landscape that needs to be backed up and monitored.

Authentication methods and policies. Settings for multifactor authentication, password policies, FIDO2 keys, and certificate-based authentication control how users prove their identity. Changes here can weaken security posture tenant-wide.

Named locations and identity governance. The configurations that define trusted networks, the access reviews that verify permissions over time, and the entitlement management settings that control access to resources are all Entra ID objects that attackers can target.

Privileged Identity Management (PIM) configurations. For organizations using PIM, the role eligibility settings, approval workflows, and activation policies are critical security controls. Lose these configurations, and you lose the governance layer protecting your most sensitive permissions.

B2B guests and external identities. External collaboration settings, guest user access restrictions, and cross-tenant synchronization configurations all live in Entra ID. These often represent some of the riskiest pathways into your environment.

Here's what concerns me most in conversations with customers: many organizations have comprehensive backup strategies for their on-premises infrastructure, but they haven't extended that thinking to Entra ID. Some didn't even realize it needed protection. The dangerous assumption is that because it's Microsoft's cloud service, it's inherently protected and recoverable. That's the same misconception I see with Microsoft 365 workloads. Mailboxes, OneDrive, SharePoint; organizations often assume that because these services are hosted by Microsoft, the data is automatically backed up and recoverable. But Microsoft's shared responsibility model makes it clear: they're responsible for the infrastructure availability, but you're responsible for your data and configuration protection. Accidentally deleted a critical SharePoint site? Malicious insider wiped mailboxes? Ransomware encrypted OneDrive files? Without third-party backup, your recovery options are limited and time-bound.

The same applies to Entra ID, except the stakes are arguably higher. Lose your SharePoint data and it's a business disruption. Lose your identity infrastructure and your entire organization stops functioning.

That assumption is dangerous.

Entra ID objects can be deleted or modified in seconds, and if you don't have proper backup and recovery mechanisms in place, that damage can be permanent. Microsoft's native recycle bin helps with some scenarios; it can recover deleted users, groups, and applications within a 30-day window. But it's not a comprehensive recovery strategy. It doesn't capture configuration changes, it doesn't preserve all object relationships, and it certainly doesn't help you roll back to a point-in-time before a sophisticated attacker made subtle changes across dozens of objects.

I've heard from customers who realized this during an incident, or worse, too late, that they have no way to restore their Entra ID configuration to a known-good state. That's a terrifying position to be in when your entire workforce authenticates through that system and your business-critical SaaS applications depend on it.

The Fragmentation Problem

One pattern I see repeatedly: organizations have pieces of this puzzle, but the pieces don't connect.

They've got a backup solution that captures AD, but it wasn't designed for rapid forest recovery. They've got a SIEM collecting identity logs, but no automated response playbooks. They've got some monitoring on Entra ID, but it doesn't correlate with what's happening on-premises.

That fragmentation creates gaps, and gaps create dwell time. The longer an attacker has access to identity systems before detection and response, the more damage they can do and the harder recovery becomes.

The organizations doing this well are the ones treating identity resilience as an integrated discipline, not a collection of point solutions. Detection informs response. Response feeds recovery. Recovery validates against known-good baselines. It's a cycle, not a checklist.

What to Look For

When working with customers evaluating their data protection capabilities, identity protection cannot be an afterthought anymore. There are specific features that separate adequate solutions from ones that will actually work when things go wrong:

Immutable, air-gapped backups. Your identity backups need to be stored separately from your production environment, ideally in a location that attackers can't reach even if they compromise your primary infrastructure. If ransomware can encrypt your AD backups along with everything else, you haven't improved your position.

Full forest recovery, not just individual DCs. Restoring a single domain controller is a very different operation than recovering an entire Active Directory forest. The interdependencies between domain controllers, the SYSVOL replication, the trust relationships: all of these need to be handled correctly or you end up with a partially functional environment that creates more problems than it solves.

Clean room recovery capabilities. After a serious compromise, you may not be able to trust any of your existing infrastructure. The ability to stand up AD on completely new hosts, potentially with a new IP schema, is critical. You need to be able to rebuild from scratch in an isolated environment before reconnecting to production.

Granular restore with relationship preservation. For Entra ID especially, it's not enough to restore individual objects. Users belong to groups, groups have role assignments, applications have service principals with specific permissions. A recovery solution that restores objects but loses these relationships leaves you with hours of manual reconstruction work, assuming you even know what the relationships were supposed to be.

Coordinated hybrid recovery. If you're running hybrid identity (and most organizations are), you need recovery that understands the relationship between on-premises AD and Entra ID. Restoring one without considering the other can create synchronization nightmares and authentication failures.

Point-in-time flexibility. You need to be able to restore to a specific moment before the compromise occurred. This requires retention policies that keep enough history to get back to a known-good state, which might be days or weeks before you detected the breach.

Validation and integrity checking. The ability to compare your restored state against a known-good baseline and flag anomalies. Did any new accounts appear? Were any group memberships modified? Were there policy changes that shouldn't have happened? Without this validation step, you might restore the very persistence mechanisms the attacker planted.

Continuous exposure monitoring. Beyond backup and recovery, you need visibility into indicators of exposure: the misconfigurations and risky settings that attackers can weaponize. Excessive service account privileges, stale admin accounts, misconfigured delegation settings. The best solutions monitor hundreds of these indicators across both AD and Entra ID and surface them before they become attack vectors.

Automatic rollback of malicious changes. When a risky change is detected (a new account added to Domain Admins, a conditional access policy modified, a service principal granted excessive permissions), the ability to automatically undo that change can mean the difference between a contained incident and a full-blown breach. This requires change capture that works independently of native logging, since attackers often disable or circumvent those logs.

Starting the Conversation

If you're not sure where your organization stands on identity resilience, here are the questions I'd start with:

• When was the last time you tested a full Active Directory forest recovery? Not a single DC, the whole forest.
• Can you restore Entra ID to a specific point in time, including all configurations, group memberships, and application permissions?
• How quickly would you detect a new service account being created with domain admin privileges?
• Do you have visibility into changes to conditional access policies before they take effect?
• If you restored AD from backup today, how would you validate it doesn't contain attacker persistence mechanisms?

If those questions make you uncomfortable, good. That discomfort is the beginning of building something more resilient.

The Path Forward

Identity infrastructure used to be something you stood up once and maintained quietly. That era is over. The systems that control authentication and authorization are now among the most valuable targets in your environment, and they need to be protected accordingly.

This isn't about fear. It's about acknowledging that the threat landscape has evolved and our defenses need to evolve with it. The organizations that treat identity resilience as a strategic priority, not an afterthought, are the ones that will weather the inevitable incidents without catastrophic impact.

I'll be diving deeper into specific aspects of identity resilience in future posts. There's a lot to unpack here, from technical recovery procedures to organizational readiness. But the first step is recognizing that this conversation needs to happen.

If your identity infrastructure went down tomorrow, how confident are you in your ability to recover? That's the question worth sitting with.

Working through identity resilience challenges with your organization? I'd be interested to hear what you're seeing. Connect with me on LinkedIn or reach out at mike@mikedent.io.