Zero Trust in Practice: Identity, Part 2 — Advanced Identity, from Static Roles to Dynamic Access

This is the second part in an ongoing series on Zero Trust maturity for the Identity pillar. Part 1 covered the Foundation stage: federated identity, MFA, directory sync, and audit logging. This post covers the Advanced maturity stage.

The problem with roles

Foundation-stage identity controls are a meaningful step forward. SSO replaces per-app passwords. MFA adds a second factor. Directory sync keeps access current. You’ve closed the obvious gaps.

But there’s a structural problem underneath all of it: access is still static.

Role-based access control (RBAC), the model most organizations run on, defines access at provisioning time. You join a team, someone assigns you a role, and that role determines what you can see. It’s systematic and auditable. It also has no mechanism for reflecting reality as it changes.

In practice, roles multiply and drift. Team A has leads and contributors, and so does Team B. But you can’t use a single “Lead” role across both teams, so you create “Team A: Lead” and “Team B: Lead.” Each has the same permissions, but both are scoped to their respective teams. As the organization grows, you clone and tune these roles repeatedly. When someone moves from Team A to Team X, changing “Team X: Lead” feels risky — it might impact others — so you create “Team X: Lead-new” instead.

The problem compounds. And when programs wrap, people often keep their old roles. The result is an environment where people have access far beyond what their current work requires, and similarly named roles across teams may not be equivalent.

Nobody planned for this. It just happens.

Security teams call this “access sprawl,” and it’s one of the most consistent findings in post-incident forensics. The attacker didn’t need a zero-day, they just needed the credentials of someone whose access was never cleaned up or different than required and expected.

Further, RBAC also has no concept of context. It doesn’t ask what device you’re on, what network you’re coming from, or whether your clearance is still current. It just checks your role and opens the door.

Zero Trust’s Advanced maturity stage is the answer to this: replace static role assignment with dynamic, attribute-based access control (ABAC) that reflects who you are right now, not who you were when IT provisioned you.

What attribute-based access control actually means

ABAC evaluates access decisions against a policy that combines multiple attributes simultaneously:

• User attributes: clearance level, program affiliation, organizational unit, job function
• Resource attributes: channel classification, data sensitivity, team membership requirements
• Environmental attributes: device type, network location, time of access

Instead of asking “is this person an admin?”, an ABAC policy asks something like: “does this person currently have a Secret clearance, an active affiliation with Program X, and using a managed device?” All conditions must be satisfied. If any one of them changes — a clearance lapses, a program affiliation ends, a device falls out of compliance — access adjusts automatically.

This is where data-centric security becomes critical. Regardless of where the data moves, the protection moves with it, enforced dynamically based on the current state of the person trying to reach it.

How Mattermost implements ABAC

Mattermost’s Advanced Access Controls use Common Expression Language (CEL) syntax to define access policies. CEL is readable, flexible, and precise — policies can be as simple or as granular as the organization requires.

A basic example:

user.clearance == "SECRET" && user.program_affiliation.contains("PROGRAM_X")

A more complex policy might layer in device enrollment status, network classification, or time-bound conditions, all evaluated at access time, against current attribute values.

Note: With Mattermost’s Program Masking, even the program names are hidden from administrators unless they already have access. This keeps access controls exclusively in the hands of the program’s security officer, eliminating the risk of an administrator having or misconfiguring access.

Continuous evaluation, not point-in-time provisioning

RBAC is evaluated once, at provisioning, and stays static until someone manually changes it. Mattermost’s ABAC evaluates continuously as user attributes change.

In practice this means:

• A user whose program affiliation is updated in the directory is automatically added to matching channels; no admin intervention required
• A user whose clearance lapses is automatically removed from private channels that require it
• On public channels, the policy is advisory: matching channels are surfaced as recommendations, but users aren’t forcibly removed

The same continuous evaluation applies at the team level: users who no longer match a private team’s policy are removed from the team and all its channels automatically.

This matters because the access footprint stays current. Sensitive channels don’t accumulate former members. The membership reflects the actual, present organizational state, not a provisioning decision made 18 months ago.

Attributes are only as good as their sources

ABAC policies are only as powerful as the attributes they evaluate. Mattermost supports custom user attributes — including clearance level, program affiliation, organizational unit, location — that can be sourced from:

• AD/LDAP sync: attributes flow continuously from your directory, keeping Mattermost current with authoritative enterprise data
• SAML assertions: attributes delivered at authentication time directly from your IdP
• Manual admin assignment: for attributes that don’t yet exist in upstream systems

For government and defense organizations, this means clearance levels and program affiliations managed in authoritative systems can flow directly into Mattermost access policies, with no parallel manual processes or lag between the source of truth and the enforcement point.

This is the investment that unlocks real ABAC maturity: connecting Mattermost to your authoritative attribute sources. The policies themselves are straightforward to write. Populating the attributes they evaluate is where both the work and the payoff are.

The data-centric framing for Advanced-stage conversations

At the Foundation stage, the goal was: “We protect the data wherever it lives; we don’t count on the network to do it for us.”

At the Advanced stage, that goal gets more specific: “Access reflects current reality, not historical provisioning.”

The Foundation-stage controls don’t address the risk of insider threat of accumulation. Not malicious actors necessarily, but the slow drift between who has access and who should. ABAC closes that gap automatically. The access footprint shrinks to match current operational reality, continuously, without manual cleanup cycles.

For leadership, frame it as operational hygiene that happens automatically rather than blocked by a ticket queue. For auditors, frame it as continuous authorization rather than a periodic review and management process.

What comes next

Advanced ABAC gives you continuous, context-aware access control evaluated against synced attributes. That’s a major step forward from static roles.

But it still has a ceiling: attributes are evaluated on a sync cycle. In high-stakes environments — think classified operations, real-time clearance adjudications, and mission-critical access decisions — even a short sync lag is too much.

The next post covers the Optimal identity stage: real-time clearance queries from authoritative sources, fully dynamic enforcement with no sync dependency, and what it looks like when no access decision relies on cached state.

For a full technical mapping of Mattermost’s identity capabilities to the CISA Zero Trust Maturity Model, see the Zero Trust with Mattermost documentation.