Why FISMA Compliance Programs Still Fail in 2026

Federal agencies spend real money and real staff hours getting FISMA-compliant, and a meaningful share of them still show up in a breach report within a few years of a clean assessment. That's not a contradiction — it's the predictable result of treating a point-in-time authorization as if it were a permanent security guarantee. The gap between "we passed our FISMA assessment" and "our environment is actually defensible right now" is where most federal identity incidents live, and it's a gap that recurs in the same handful of shapes across agency after agency: the same control-family findings, the same POA&M items that never quite close, the same identity governance corners that get cut under audit-season pressure and never get uncut afterward.

This is the 2026 update to an earlier Avatier post on FISMA failure modes (previously published at avatier.com/blog/fisma-fails-prevent-catastrophic), which leaned heavily on breach case studies and third-party statistics to make its case. This version drops the borrowed numbers and focuses on the pattern itself: what actually recurs in FISMA assessments and federal identity incidents, why it recurs, and what closes it. The companion FISMA compliance overview covers the framework FISMA runs on — FIPS 199 categorization, the NIST Risk Management Framework's six steps, and where 800-53 alignment stops and a real Authorization to Operate begins. This piece assumes that foundation and goes straight to where it breaks down.

Why FISMA programs fail: the pattern behind the pattern

Ask any assessor who has worked a stack of federal Security Assessment Reports what the failures have in common, and the answer isn't exotic. It's a small set of recurring habits that substitute the appearance of control for the actual thing.

Programs default to paperwork over enforced controls — a policy document exists, a control is marked "implemented" in the System Security Plan, but nothing in the actual environment technically prevents the behavior the policy prohibits. Access reviews go stale between certification cycles, so the entitlement state an assessor sees on review day isn't the entitlement state that existed the month before or the month after. Identity governance stays weak relative to everything else in the security stack, because provisioning and deprovisioning tend to be built as manual, ticket-driven processes long after network security and endpoint controls have been automated. And the whole program can drift into an audit-only mindset, where the operative question becomes "will this pass the next assessment" rather than "does this actually reduce risk," which produces controls tuned to what an assessor checks rather than what an attacker exploits.

Four failure modes, one root cause: each substitutes documentation of a control for the control actually being enforced.

None of these four patterns is a single dramatic failure. Each one is a small, individually defensible shortcut — reviewing access faster than it deserves, documenting a control instead of automating it, tracking a gap instead of closing it — that compounds across a program with hundreds of systems and thousands of accounts into an environment that looks compliant and isn't secure.

The Access Control findings that keep recurring

If there's one NIST 800-53 control family that carries the most weight in a FISMA assessment and produces the most repeat findings, it's Access Control (AC). Three sub-controls account for a disproportionate share of it.

AC-2, account management. The finding here is almost always the same shape: accounts exist in the system that don't map cleanly to an active employee, contractor, or documented business justification. Sometimes it's a contractor whose engagement ended eight months ago; sometimes it's a test account created for a migration that finished a year ago and was never deleted. Account management findings are rarely about accounts being created incorrectly — they're about accounts not being removed on schedule.

AC-3, access enforcement. This is the gap between documented policy and actual system behavior. A role is documented as having read-only access to a data set, but a manual grant made outside the standard provisioning path gave that role write access eighteen months ago, and nothing in the review process caught the mismatch because the review checked whether a policy existed, not whether the system actually enforced it.

AC-6, least privilege. This finding accumulates through role changes. Someone moves from one team to another, picks up the new team's access, and keeps the old team's access because deprovisioning on a role change is less consistently enforced than deprovisioning on termination. Over a few years and a few role changes, a single account can accumulate entitlements from four different jobs, none of which the current role requires.

All three point back to the same root cause: a provisioning and deprovisioning process that isn't tightly and automatically coupled to HR and role-change events. Fixing the finding one account at a time doesn't fix the pattern; fixing the coupling does.

POA&M mismanagement: where remediation promises go to die

A Plan of Action and Milestones exists to document a known gap, the plan to close it, and a date by which it will be closed. In a healthy program, a POA&M item is a short-lived artifact — logged, worked, closed, retired. In the programs that keep failing assessments, POA&M becomes a permanent backlog: items get logged, their milestone dates slip, they get re-logged with a new date, and the cycle repeats across multiple assessment periods without the underlying gap ever actually closing.

The reason this happens isn't usually bad faith. It's an ownership mismatch. The function that identifies and tracks POA&M items — often a compliance or GRC office — typically doesn't have the authority to reprioritize the engineering or operations team's actual work. The POA&M item competes for attention against production incidents, feature deadlines, and everything else on an IT team's plate, and without an executive sponsor treating an aging POA&M item with the same urgency as an open production risk, it loses that competition every time. The item stays open not because no one knows about it, but because knowing about it was never enough to make it someone's job to close.

The practical fix isn't a better tracking tool — most agencies already have adequate GRC tooling for visibility. It's an accountability structure where a POA&M item has a named owner outside the compliance function, a deadline tied to something with real consequences for missing it, and executive visibility into aging items before the next assessment cycle, not during it.

The identity-specific gaps: recertification, sprawl, and the joiner-mover-leaver seam

Three identity-specific failure patterns show up disproportionately often in federal environments, and each one is a place where a program can be technically compliant and still carry real risk.

Access recertification lapses. A certification campaign can run on schedule, get 100% manager sign-off, and still fail its actual purpose if the reviews themselves are low-quality. A manager reviewing forty direct reports' full entitlement lists in an afternoon, with no context on what each permission actually grants, tends to approve everything rather than investigate anything — the path of least resistance under time pressure. The auditor-actually-wants piece and the checkbox-review piece both cover this exact gap: a completed review and a meaningful review are not the same event, and an assessor who knows what to look for can usually tell the difference from the pattern of approvals alone.

Privileged and service account sprawl. Both categories tend to sit outside the standard human-identity lifecycle. A privileged account provisioned for a specific migration or incident-response engagement often survives well past the engagement's end, because no automated process is watching for its expiration the way HR-driven processes watch for a human employee's termination. Service accounts are worse in practice — created to connect two systems, granted broad access because narrowing it took more setup time than anyone had, and then left running indefinitely because rotating or revoking credentials risks breaking an integration no one currently on staff fully understands. Federal environments, with their long system lifespans and frequent staff turnover, accumulate more of this kind of orphaned non-human access than most private-sector environments do. The Privileged Access Management piece and the Service Account Governance piece both cover the governance model that closes this gap directly.

Joiner-mover-leaver (JML) gaps. The leaver half of this gets the most attention because a terminated employee retaining access is the most viscerally alarming version of the problem, but the mover half causes more actual entitlement bloat. Every transfer, promotion, or team change is a moment where old access should be removed and usually isn't, because deprovisioning on a move is far less consistently automated than provisioning new access for the new role. Multiply that across a career's worth of role changes inside one federal career-employee population — which tends to be longer-tenured than private-sector comparables — and the accumulated excess access becomes substantial before anyone notices it in a review.

Compliance is not security: a passed audit is a snapshot

The single most important thing to internalize about FISMA — or any compliance framework with an access-control component — is that passing an assessment measures a moment, not an ongoing state. An Authorization to Operate reflects the system as it existed when the Security Assessment Report was produced. Every account created after that date, every role change, every new integration, every service account someone spun up to solve an urgent problem, happens outside the window the assessment actually examined.

A checklist can be fully checked and a former employee's badge can still be live — compliance measured the process, not the entitlement state.

This is why a compliant environment can still get breached, and it's not a hypothetical. An attacker doesn't care whether a control is documented in a System Security Plan; they care whether it's actually enforced against the specific account and the specific path they're using right now. A former employee's badge revoked on paper but still active in a downstream system is indistinguishable, from the attacker's perspective, from an account that was never reviewed at all. The FISMA framework itself acknowledges this with its continuous-monitoring requirement under the Risk Management Framework's final step — the problem is that continuous monitoring is the step most programs treat as optional relative to the ones that produce assessment paperwork.

Closing that gap means treating the assessment date as the start of the clock, not the finish line — building the environment to stay in the state the assessor reviewed, rather than drifting from it the day after the report is filed.

The identity-governance fixes that close these gaps

Every failure pattern above traces back to the same root cause: entitlements that were correct once and were never re-verified or corrected as circumstances changed. The fix isn't a new category of control — it's making the controls that already exist on paper actually operate continuously instead of periodically.

The fixes aren't new controls — they're the existing control set enforced continuously instead of checked periodically.

Least privilege enforced at grant time, not caught at review time. Role-based provisioning that grants exactly what a job function needs, rather than granting broadly and hoping a future review catches the excess, prevents the AC-6 pattern from accumulating in the first place.

Continuous access certification instead of point-in-time campaigns. Reviews that run against current risk signals — dormant entitlements, access outside a peer group's norm, permissions unused for months — surface the accounts worth a manager's actual attention instead of asking them to evaluate all of them equally.

Automated deprovisioning tied to HR and role-change events. The AC-2 and JML patterns both close the same way: when a termination, transfer, or contract end date fires automatically as a deprovisioning trigger instead of depending on a manager remembering to file a ticket.

Evidence generated as a byproduct of enforcement, not assembled for the audit. When certification results, approval records, and access-change history are captured continuously as part of normal operation, producing a Security Assessment Report's evidence package becomes an export instead of a scramble — and the evidence reflects the actual current state, not a state reconstructed after the fact.

A practical checklist for federal IAM and security teams

Before the next assessment cycle, a federal IAM or security team can get a reasonably honest read on where their program actually stands by working through a short set of specific questions, not a general policy review:

• Pull a random sample of accounts and check whether each one maps to an active employee, contractor, or documented business need — don't audit the policy, audit the actual account list.
• Check how many POA&M items have slipped past two or more milestone dates, and ask who currently owns closing each one — a stalled item with no named owner outside the compliance function is a structural risk, not an oversight.
• Review the last certification campaign's approval rate. A campaign where managers approved close to 100% of entitlements without exception is a signal the review was procedural, not substantive.
• Inventory privileged and service accounts separately from human user accounts, and confirm each one has an owner, a documented purpose, and a credential rotation schedule.
• Trace what actually happens, end to end, when an employee transfers teams — not just what happens on termination. The mover path is where the most silent entitlement bloat accumulates.
• Confirm that evidence for the AU-2/AU-6 audit and accountability controls is being generated automatically, not assembled manually in the weeks before an assessment.

None of these checks require new tooling to run once. What they reveal is whether the current program depends on manual diligence holding up indefinitely — which is the condition every failure pattern in this piece traces back to.

What Avatier ships toward this pattern

Avatier Identity Anywhere Lifecycle Management is built around closing the specific gaps above rather than documenting around them. HRIS-driven joiner-mover-leaver automation ties provisioning and deprovisioning directly to employment and role-change events, which is the structural fix for both the AC-2 account management pattern and the mover-path entitlement bloat described above — the HRIS-Driven Lifecycle piece covers the integration architecture in more depth. Continuous, risk-signal-driven access certification replaces the point-in-time campaign that produces low-quality rubber-stamp approvals, addressing the recertification-lapse pattern directly. Governance for privileged and service accounts extends the same lifecycle discipline to the non-human identity population that standard human-identity reviews consistently miss.

Audit evidence — certification results, approval chains, entitlement change history — is generated continuously as a byproduct of the platform's normal operation, which is what turns a Security Assessment Report evidence request from a scramble into an export. That architecture is the same one underpinning Avatier's coverage of SOX §404 access controls, HIPAA §164.312 technical safeguards, and PCI DSS v4.0.1 access control requirements — the same underlying control discipline, mapped to each regime's specific language, rather than rebuilt from scratch for each one.

Avatier's own compliance posture is published at the Avatier Trust Center: SOC 2 Type II with zero exceptions, ISO/IEC 27001:2022 certification, PCI DSS v4.0.1 compliance, CSA STAR Level 1, NIST 800-53 Rev. 5 aligned architecture, FedRAMP-aligned controls, FIDO2-compatible authentication support, and status as a CISA Secure-by-Design Pledge signatory. None of that constitutes a FedRAMP authorization or an agency's own Authorization to Operate — it's a documented control environment an agency's assessors and Authorizing Official can evaluate, not a substitute for the agency running its own categorization, assessment, and authorization process. The companion FISMA compliance overview covers that distinction in full.

What tooling doesn't solve

It's worth closing honestly: no identity governance platform, however well it automates deprovisioning or generates evidence, fixes a program where no one owns closing a POA&M item, where leadership treats the annual assessment as the whole job rather than the checkpoint, or where the IAM team is two people covering a system portfolio that needs eight. Tooling closes the mechanical gap between a policy and its enforcement. It does not create executive sponsorship for treating identity risk as an operational priority between assessment cycles, and it does not staff a security team that's been asked to do more with a budget that hasn't kept pace with the system estate it's responsible for governing.

The failure patterns in this piece are technical in their symptoms — an orphaned account, a stale certification, an unrotated service credential — but they're organizational in their cause. A federal agency that fixes the accountability gap behind its POA&M backlog and gives its identity team the automation to make continuous enforcement actually continuous will close most of what's described here. A federal agency that buys a platform and expects it to compensate for the first problem without addressing the second will pass its next assessment and still be exactly where it started.