What AB 869 proposed
California AB 869, introduced by Assemblymember Jacqui Irwin in February 2025, proposed requiring state agencies to achieve Advanced maturity under CISA's Zero Trust Maturity Model by June 1, 2026 and Optimal maturity by June 1, 2030. Correction: This article previously described AB 869 as signed law. The official text and history reviewed establish a proposal, not enactment; its proposed dates should not be treated as enforceable deadlines. The proposal remains useful as a design case: it combines maturity targets, technical priorities and reporting, while leaving agencies to solve the detailed sequencing problem. Before relying on any statutory deadline, buyers should verify the final enacted text, applicability and effective dates rather than infer enactment from a bill's wording.
Treat maturity as evidence across an architecture
CISA's model organizes zero trust around Identity, Devices, Networks, Applications and Workloads, and Data, with cross-cutting capabilities for visibility and analytics, automation and orchestration, and governance. Traditional, Initial, Advanced and Optimal are maturity stages, not a product checklist. An agency can progress at different rates across functions. Multi-factor authentication, endpoint detection and response, and logging are valuable controls, but deploying them does not by itself establish a maturity rating. The introduced AB 869 text lists those controls as priorities.
Assessors still need to inspect how identity, device posture, access policy, monitoring and response work together. A claim of enterprise maturity requires evidence across the applicable model, not a marketing label on a purchased tool.
Start with identity visibility and dependencies
The practical sequencing problem for state agencies is that zero trust architecture cannot be purchased as a product and deployed sequentially across legacy infrastructure. A legacy state environment may contain LDAP directories, on-premises applications built before modern identity standards existed, and procurement relationships negotiated before zero trust was part of state IT vocabulary. A practical starting point is identity visibility: agencies that cannot see all of their identities — including service accounts, contractor credentials, and application identities — cannot reliably apply identity-based policy to the full estate.
That identity work is an enterprise architecture effort as well as a tooling decision. A single identity store is not always necessary; governed federation can also support consistent policy. It surfaces entanglement: legacy applications that authenticate against Active Directory silos, claims databases that predate SAML, benefit systems with embedded credential stores that predate the concept of federation.
Maryland provides a separate policy example. Its Cybersecurity and Privacy Policy Suite, modernized in February 2026, integrates zero trust principles through governance policies, functional policies and technical standards for the executive branch. That is evidence of a policy approach, not proof that every agency has completed implementation.
Sequence changes without breaking services
The architecture question extends beyond one bill. An agency needs to know which users, devices, workloads and data flows exist before deciding where to enforce access and how to detect failures. An identity proxy may help protect a legacy application, but it does not automatically fix the application's authorization logic or remove every bypass path. Network segmentation needs an application dependency map and a test plan so tighter controls do not interrupt essential services. A sensible first increment may focus on privileged access or a sensitive application rather than enterprise-wide segmentation.
The sequence should reflect risk, prerequisites and service continuity. These are implementation recommendations, not a claim that California or Maryland mandates a single order of work.
Separate legal compliance from security progress
The broader lesson is that zero trust planning must distinguish binding obligations, reference frameworks and proposed legislation. Federal requirements applicable to particular agencies do not automatically bind state government, and a proposed state bill is not an enacted compliance obligation. A state may still choose to use CISA's maturity model to improve security and report progress. The useful report connects each claim to operating evidence: which identities are covered, how exceptions are handled, what access is denied, what signals trigger response and what remains outside scope.
An attestation that lists products but does not test behavior leaves the hard work unresolved. Leadership should fund the identity, segmentation, data classification and monitoring work required for the selected services, while making dependencies and residual risk visible. That approach remains valuable whether a legislature ultimately adopts a specific maturity deadline or not.
Build the first defensible increment
- Establish the applicable requirement. Record enacted laws, binding state policy and contract conditions separately from proposed bills and voluntary reference models. Verify versions and scope.
- Map one critical service. Inventory identities, service accounts, devices, applications, data and dependencies. Record exceptions and unsupported components before selecting controls.
- Improve identity and privileged access. Define account ownership, authentication strength, least privilege and revocation. Test service accounts and emergency-access procedures as well as employee login.
- Apply risk-based boundaries. Pilot segmentation or application access controls with dependency tests, monitoring and a rollback path. Confirm that unauthorized access is denied without blocking required work.
- Demonstrate progress by function. Collect test results and coverage evidence for the chosen maturity functions. Assign owners and dates to gaps instead of making a blanket enterprise claim.
What to measure
- Coverage: identities, devices and services actually subject to the tested policy.
- Enforcement: denied unauthorized requests and documented exceptions, including alternate access paths.
- Resilience: essential service behavior during identity outages, policy changes and incident containment.
Sources and further reading
- Maryland Cybersecurity and Privacy Policy Suite — February 2026 executive-branch policy structure
- California AB 869 introduced bill text — proposal language; not proof of enactment
- California AB 869 official history — legislative actions returned by the official record
- California Franchise Tax Board bill analysis — analysis explicitly describes what the bill would require
- CISA maturity-model announcement — model stages, pillars and incremental implementation
Spartan X's cybersecurity and engineering practices focus on the operating evidence behind a security claim: what is covered, what access is enforced and how the service behaves when something fails. That is the work that makes a zero trust roadmap credible.
