TIGTA’s findings are not obscure technical edge cases. They describe a failure mode that is structurally common to every organization managing privileged access across hybrid cloud environments where the infrastructure ownership and the security monitoring responsibility sit in different organizational lanes.

What the Investigation Actually Found

The core finding centers on the IRS’s Privileged User Management Access System, known as PUMAS. The IRS mandates PUMAS use specifically to create audit trails for all administrative actions requiring elevated privileges across its systems. That requirement exists because privileged account activity is the highest-risk category of access in any sensitive data environment. When administrators can act without traceable oversight, the conditions for both insider threat and external compromise are structurally present.

Despite that mandate, the IRS data platform has never been fully integrated with PUMAS. The integration failure was not unknown. The platform management team identified the problem in January 2024, created a Plan of Action and Milestones to address it, and then did not resolve it. The reason the fix stalled is architecturally instructive: the IRS and the Department of the Treasury‘s Workplace Community Cloud operate in different active directory environments, which means PUMAS lacks the permissions required to manage users and accounts outside the IRS network boundary. The platform is hosted on the Treasury cloud, placing it structurally outside the reach of the IRS’s own privileged access management tooling.

The consequence of that gap is not theoretical. TIGTA found no evidence that privileged account activity on the platform was being actively monitored. The platform team indicated that the Treasury Shared Services Security Operations Center was responsible for watching privileged accounts on the Treasury cloud. The IRS could not produce documentation confirming those monitoring activities actually occurred.

And within that unmonitored environment, TIGTA identified a privileged user account without approved access that successfully logged into the platform. The unauthorized login was attributed to an administrative error in the manual approval process.

A manual approval process managing access to a platform holding sensitive data on millions of taxpayers. An administrative error creating unauthorized privileged access. No documented evidence of monitoring. These are not edge cases. They are the predictable outcomes of a governance model that was not designed to span the infrastructure boundary where the platform actually lives.

The Active Directory Boundary Problem Is Not Unique to the IRS

The specific technical explanation for why PUMAS integration failed is worth dwelling on because it will be immediately familiar to security architects managing enterprise cloud environments.

The IRS controls its own active directory environment. The Treasury cloud operates a separate one. PUMAS was built to manage users within the IRS network boundary. When the data platform was deployed on Treasury infrastructure, it moved outside that boundary, and the privileged access management tooling that was supposed to govern it no longer had the permissions to do so.

This is an extremely common failure pattern in enterprise cloud migration and shared infrastructure deployments. An organization deploys privileged access management tooling against its own identity environment. It then moves a workload, or inherits one, or acquires a platform that runs on a partner’s cloud infrastructure where a different identity provider is in control. The PAM tooling does not follow because it cannot reach across that boundary. The security team assumes monitoring is happening on the other side. Neither side has documentation confirming that the monitoring is actually occurring. An access gap forms in the seam.

Every enterprise that has gone through a cloud migration, a merger and acquisition integration, or a shared services arrangement with a cloud provider has created some version of this gap. The IRS example makes it visible and formally documented in a way that private sector organizations rarely achieve for their own environments.

Manual Processes as a Systematic Vulnerability

The unauthorized login documented in the TIGTA report was attributed to an administrative error in the manual approval process. That attribution deserves more scrutiny than it typically receives in incident post-mortems.

Manual approval processes for privileged account access are a governance design choice, not an unavoidable constraint. They exist because automated provisioning and deprovisioning requires integration between identity management systems, access review workflows, and the underlying infrastructure where accounts are created. When that integration is absent, as it is in the IRS case due to the active directory boundary problem, manual processes fill the gap.

Manual processes handling privileged access at scale produce errors at a predictable rate. An account is approved in the wrong system. A deprovisioning request is not propagated across all relevant environments. A role assignment persists past its intended duration because the review cycle that should catch it is not automated. A user with historical access retains it through an infrastructure migration because the migration process did not include an access reconciliation step.

Each of those errors is individually attributable to human mistake. Collectively they represent a systematic vulnerability that is the direct consequence of governance architecture that depends on human consistency in environments where automated enforcement is absent.

TIGTA’s four recommendations to the IRS all address dimensions of this same root cause: integrate the platform with PUMAS, resolve the infrastructure issues between network environments, make access notifications timely, and pursue automated sign-off processes for user accounts. The IRS agreed with all four. That agreement is meaningful because it represents a formal acknowledgment that the manual process model is not a viable long-term governance approach for a platform at this sensitivity level.

Enterprise Risk Implications That Cannot Be Delegated Away

There is a governance assumption embedded in the IRS response to TIGTA’s monitoring question that enterprise security leaders should recognize and resist in their own programs.

When asked about monitoring of privileged accounts on the Treasury cloud platform, the IRS indicated that the Treasury Shared Services Security Operations Center was responsible. The IRS could not produce evidence that monitoring was occurring. The implicit assumption was that because responsibility had been assigned to another party, the monitoring requirement had been satisfied.

That assumption is a governance failure regardless of whether the other party is actually performing the monitoring. Accountability for privileged access oversight on a system holding sensitive organizational data cannot be fully delegated to a shared services provider without documented evidence that the monitoring is occurring, defined escalation paths when anomalies are detected, and regular verification that the monitoring coverage is complete.

Shared cloud infrastructure creates genuine complexity in monitoring ownership. The infrastructure provider may be responsible for platform-level security. The application owner is responsible for application-level access governance. The security operations team is responsible for anomaly detection and incident response. Those responsibilities are not mutually exclusive, but they do not automatically cover each other. In the gaps between them is where unauthorized access, unmonitored privileged activity, and undetected compromise accumulate.

Enterprises that have deployed workloads on hyperscaler infrastructure, used managed service providers for security monitoring, or inherited cloud platforms through acquisition need to verify, not assume, that privileged account monitoring responsibilities are being executed by whoever formally owns them.

What Security and Compliance Teams Should Act On Now

The TIGTA findings translate directly into a set of verification priorities for enterprise security programs managing cloud infrastructure with similar characteristics.

The most immediate question is whether privileged access management tooling has unambiguous coverage across every environment where sensitive workloads run, including environments hosted by third parties, shared services providers, or infrastructure acquired through business combinations. Assumed coverage is not coverage.

The second question is whether evidence of monitoring activity exists and is being retained. The IRS case demonstrates that “we believe monitoring is occurring” and “we have documentation that monitoring occurred” are meaningfully different statements. The latter is the only one that satisfies audit requirements or provides genuine assurance against unauthorized access.

The third question is whether manual processes are managing any access approvals for privileged accounts on sensitive systems, and if so, what the error rate of those processes is. Manual processes at scale produce errors. The question is whether the organization knows its error rate or is discovering errors through watchdog reports and unauthorized access incidents.

The fourth question, and the most structurally important one, is whether the active directory and identity management architecture has boundary gaps between environments where different infrastructure owners are in control. Those gaps are where PAM tooling loses visibility, monitoring responsibility becomes ambiguous, and unauthorized access finds its path.

The Broader Pattern Behind a Single Watchdog Report

The IRS findings will be resolved through the four recommendations TIGTA issued and the corrective action plan that will follow. The platform will eventually be integrated with PUMAS. The active directory boundary problem will be addressed through coordination between the IRS and Treasury. Automated account management processes will reduce the manual error surface.

But the pattern the report documents is not being resolved by those recommendations. It is present in every enterprise that has deployed cloud infrastructure across organizational boundaries without ensuring that privileged access governance followed the workload. It is present in every shared services arrangement where monitoring responsibility has been assigned without verification. It is present in every access review process that depends on human consistency to maintain a control that should be enforced by architecture.

A $178 million federal platform with unmonitored privileged accounts and a documented unauthorized login is a high-visibility example of a low-visibility problem. The organizations that read this report as an external curiosity rather than an internal diagnostic are the ones most likely to receive their own version of the same findings from an auditor, a regulator, or a breach investigator.

The seam between infrastructure environments is where governance goes quiet. That is where the attention needs to go.

Research and Intelligence Sources: TREASURY INSPECTOR GENERAL FOR TAX ADMINISTRATION, Watchdog Report

To participate in our interviews, please write to our CyberTech Media Room at info@intentamplify.com