Securing Hybrid IT: Applying CISA's SCuBA Guidelines to On-Prem AD and Azure AD

Most enterprises never made a clean jump from on-premises Active Directory to the cloud. They landed somewhere in between, and stayed there — years past what anyone originally called a "transition period." Legacy line-of-business apps still need low-latency access to an on-prem AD, sensitive workloads stay put for regulatory reasons, and meanwhile every new SaaS tool, every Microsoft 365 rollout, and every remote-work initiative adds another cloud identity layer on top. That's hybrid IT, and it isn't a phase — for most organizations it's the permanent operating model.

The problem is that identity and access management (IAM) tooling rarely evolved to match. Admins end up running two parallel identity systems — on-prem AD and Azure AD (or another cloud IdP) — stitched together with synchronization jobs, custom scripts, and a lot of manual double-entry. The Cybersecurity and Infrastructure Security Agency (CISA) recognized this gap explicitly in its Secure Cloud Business Applications (SCuBA) project, publishing hybrid identity solutions architecture guidance aimed at exactly this seam between on-prem and cloud identity. This article walks through where hybrid identity actually breaks down, what SCuBA recommends, and how to translate that guidance into controls you can implement.

What hybrid identity actually looks like

In a hybrid architecture, a single employee typically has two parallel identity footprints: an on-prem AD account governing access to internal file shares, legacy applications, and site logins, and a cloud identity — often Azure AD, synchronized from that same on-prem account — governing Microsoft 365, SaaS single sign-on, and cloud-native services. Directory synchronization tools keep the two loosely in step, but "loosely" is the operative word: sync intervals, conflicting attribute sources, and manually-managed exceptions all introduce drift between what an admin thinks a user's access looks like and what it actually is.

Layer in a second or third cloud platform — Google Workspace for a subset of departments, an independent HCM system, an Exchange Server that hasn't been fully migrated — and the picture gets messier still. Every one of those platforms has its own user objects, its own group model, and often its own authentication path. None of this is unusual; it's simply what happens when an organization adopts cloud services incrementally instead of migrating everything on a single weekend.

Why two identity planes are harder to secure than one

The security cost of running parallel identity systems shows up in a handful of predictable, recurring ways:

• Duplicated provisioning effort. Onboard one new employee and an admin using native tools has to create a matching identity in AD, then again in Azure AD or Microsoft 365, then again in Google Workspace, then again in whatever else the role requires — each with its own console, its own naming convention, and its own chance to be forgotten or done inconsistently. The same duplication applies in reverse at offboarding, which is the more dangerous direction: a missed step there leaves a live account behind.
• Repeated and reused credentials. When employees juggle logins across systems that were never unified under single sign-on, password fatigue sets in and the same password gets reused across applications. That single habit is what turns one leaked credential into a foothold across multiple systems, and it's exactly the mechanism behind credential-stuffing and brute-force campaigns.
• Low visibility into indicators of compromise. Splitting activity across two or more logging domains means SOC teams are working from a fragmented, partially-duplicated view of the network. A pattern that would be an obvious red flag in a single consolidated timeline — repeated failed logins, an unusual process spawned from an unexpected parent, a spike in privileged file access — can sit unnoticed across separate log stores long enough for an attacker to complete lateral movement.
• Inconsistent compliance reporting. Most compliance frameworks require organizations to show who accessed what, when, and from where, across the full environment — not just the on-prem half or the cloud half. Assembling that picture manually from disconnected systems is slow, error-prone, and exactly the kind of piecemeal reporting that turns a routine audit into a costly one.

Every unmanaged seam between identity systems is a place where an attacker only has to be right once, and your monitoring only has to miss once.

What CISA's SCuBA guidance actually recommends

SCuBA's hybrid identity solutions architecture guidance isn't a product endorsement — it's a set of architectural principles for securing the connective tissue between on-prem and cloud identity, aimed primarily at federal agencies but broadly applicable to any hybrid enterprise. Two recommendations come up repeatedly and are worth calling out specifically:

First, deploy multi-factor authentication (MFA) and single sign-on (SSO) consistently across both environments, treating phishing resistance as a baseline expectation rather than an aspiration. A hybrid environment where MFA is enforced in the cloud but optional on-prem, or where SSO covers half the application portfolio, is only as strong as its weakest enforced path — and attackers reliably find that path.

Second, apply behavioral, risk-based monitoring to identity activity rather than relying on static rules alone. CISA specifically frames this around establishing what normal user behavior looks like, which assets carry the most risk, and who should plausibly be requesting access to a given resource — then flagging deviations from that baseline. That's a meaningfully higher bar than traditional signature-based alerting, and it requires visibility that spans both identity planes, not one.

Underneath both of these sits a structural precondition the guidance keeps returning to: you can't apply consistent MFA, consistent SSO, or consistent behavioral baselining to an identity estate that's split across disconnected consoles. Unification isn't a nice-to-have layered on top of the security controls — it's the thing that makes the controls possible to apply consistently in the first place.

The controls that unify a hybrid identity estate

Translating that guidance into practice comes down to five control areas, each addressing one of the gaps above:

Unified identity lifecycle management

Provisioning, modification, and deprovisioning need to happen from one workflow that fans out to every connected directory and application, not from five separate admin consoles run in sequence. Template-based creation — pulling attributes from an HR system so a new hire's department, title, and group memberships populate consistently across AD, Azure AD, Exchange, and any connected SaaS platform — removes both the manual labor and the inconsistency that comes with doing it by hand five times. The same logic matters even more at offboarding: a single deprovisioning action that actually reaches every connected system is what prevents an account in the third or fourth platform down the list from quietly staying active.

Centralized MFA across endpoints and applications

MFA needs to cover the full surface — Windows, macOS, and Linux logins, VPN and RADIUS-based gateways, Outlook Web Access, and cloud application sign-ins — under one policy, not a patchwork where cloud apps require a second factor and legacy on-prem systems don't. Supporting a broad range of authentication factors, rather than mandating a single hardware token, is what makes org-wide enforcement realistic without constant help-desk friction over lost devices.

Single sign-on that spans on-prem and cloud

SSO built on standard protocols (SAML, OAuth, OpenID Connect) collapses the number of credentials a user juggles, which directly attacks the password-reuse problem — there's simply less to reuse when one authentication event covers both the internal application and the SaaS tool. It also gives security teams one place to revoke access instantly rather than chasing sessions across systems.

Real-time, cross-environment change auditing

Detecting the indicators of compromise that matter — anomalous logon patterns, privilege escalation, unusual file or folder activity, a spike in failed authentication attempts — requires a single audit trail spanning both AD and the cloud directory, correlated automatically rather than reviewed log-by-log across separate consoles. This is also where the behavioral baselining CISA calls for actually becomes achievable: you can't baseline "normal" against a dataset that's missing half the activity.

Consistent compliance and backup/recovery

Regulatory frameworks like HIPAA, SOX, and GDPR don't care which directory an access event happened in — they expect one coherent answer to "who accessed what, and when." Reporting built to span both environments turns an audit from a multi-week evidence hunt into a scheduled export. The same logic extends to disaster recovery: object-level backup and restoration across on-prem AD, Azure AD, and connected mail and collaboration platforms means a bad change or a ransomware event doesn't require rebuilding half the identity estate from scratch.

Platforms purpose-built for this problem, like ManageEngine AD360, package these five control areas into a single console spanning AD, Azure AD, Microsoft 365, Google Workspace, and Exchange — which is precisely the kind of consolidation SCuBA's guidance points toward: fewer disconnected admin surfaces, one policy for MFA and SSO enforcement, and one correlated audit trail instead of five partial ones. Whether an organization builds that unification through an integrated platform or through carefully-wired native tools, the underlying requirement from the guidance doesn't change — the seam between on-prem and cloud identity has to be actively managed, not left to sync jobs and best intentions.

A real-world example

Consider a mid-sized healthcare-adjacent logistics company running on-prem AD for its warehouse management systems and Azure AD for Microsoft 365 and a handful of SaaS tools. A departing warehouse supervisor's AD account gets disabled the day they leave — HR's exit checklist covers that — but the Azure AD account, provisioned separately eighteen months earlier by a different admin during a Microsoft 365 rollout, isn't on that checklist at all. It stays active with mailbox access and Teams membership for four months before a routine license-cost review turns it up.

Nothing malicious happened in this case, but the exposure window was real: four months of a live, unmonitored account with mailbox access tied to a former employee, invisible to anyone until a cost audit — not a security review — happened to surface it. The fix wasn't a better offboarding checklist; checklists that span two disconnected consoles fail exactly this way eventually. The fix was collapsing provisioning and deprovisioning into one workflow that touches every connected directory the moment HR marks the employee as terminated, backed by a unified audit view that would have flagged the still-active cloud session well before a billing report did.

Common mistakes to avoid

• Treating directory sync as identity unification. Tools that synchronize AD to Azure AD keep attributes loosely aligned, but they don't give you a single provisioning workflow, a single MFA policy, or a single audit trail. Sync is plumbing, not governance — it moves data between two systems that are still independently managed.
• Enforcing MFA and SSO inconsistently across environments. Rolling out strong authentication to cloud apps first and leaving on-prem systems on password-only "for now" is how that gap becomes permanent. Attackers don't respect your migration roadmap; they'll use whichever path is weaker today.
• Auditing each environment in isolation. Reviewing on-prem AD logs and cloud sign-in logs as two separate exercises, on two separate schedules, means correlated attack patterns — the kind that span both environments by design — never get connected until after the fact, if at all.

Frequently asked questions

Is SCuBA a compliance requirement, or just guidance?
SCuBA originated as CISA guidance primarily for U.S. federal civilian agencies and their cloud deployments, so it carries mandatory weight in that context. For private-sector organizations it isn't a regulatory requirement, but the underlying architecture recommendations — consistent MFA and SSO, behavioral monitoring, unified visibility — are widely applicable best practice for any organization running hybrid AD and cloud identity, regardless of sector.

Does adopting these controls mean abandoning on-prem AD entirely?
No. SCuBA's hybrid guidance explicitly addresses organizations that will run on-prem and cloud identity side by side for the foreseeable future — it's not a migration mandate. The goal is securing the hybrid state itself, not accelerating a full cloud move that many organizations have legitimate reasons to delay.

Where should a resource-constrained IT team start?
Start with provisioning and deprovisioning, since that's where duplicated effort and stale accounts originate. A single onboarding/offboarding workflow that reaches every connected directory closes the highest-risk gap fastest, and it makes every control layered on top of it — MFA enforcement, SSO rollout, unified auditing — easier to implement consistently, because you're no longer managing identity truth in five different places.

Hybrid IT isn't a temporary awkward phase between on-prem and cloud — for most organizations, it's simply what the environment looks like for years at a stretch. Treating the seam between AD and Azure AD as a permanent architectural feature, rather than a gap to be closed later, is what actually reduces risk: unify the identity lifecycle, enforce authentication consistently across both planes, and give the SOC one correlated view instead of two partial ones. That's the throughline of CISA's SCuBA guidance, and it holds regardless of which specific tools an organization uses to implement it.