Every role-based access model eventually meets the organisation it cannot quite describe. The engineer seconded to another department for a quarter. The access that should exist only while a certification is valid, or only for staff in a particular location, or only until a project end date passes. Pure RBAC answers these with proliferation - a role per exception - until the role catalogue itself becomes unreviewable, or with manual grants that depend on someone remembering to reverse them. Both answers decay into the same audit finding: access whose justification expired while the access did not.
The enterprise challenge: facts change faster than grants
Access is supposed to follow facts - who you are, where you sit, what you are currently assigned to. But in ticket-driven administration, access follows events that someone noticed and actioned. When the fact changes quietly - the secondment ends, the contractor's engagement extends, the certification lapses - no ticket fires, and the access drifts out of alignment with its justification. Multiply across thousands of users and dozens of attributes and the drift is not an edge case; it is the steady state that access reviews exist to periodically mop up.
Why static grants cannot track a moving organisation
The defect is structural: a static grant encodes a decision, not the conditions the decision depended on. When conditions change, the grant persists because nothing connects it back to them. Role explosion attempts to encode conditions as ever-finer roles, but a role is still a static object - someone must assign and unassign it as facts move. What tracking a moving organisation actually requires is policy that references the facts directly and re-evaluates when they change.
The Tanflow approach: policies bound to attributes
The Tanflow IAM Suite's Dynamic Policies capability provides exactly this: attribute-based access that, in Tanflow's own phrase, recalculates itself as facts change. Policies express access in terms of identity attributes - the department, location, employment type, assignment and other facts held in the Identity Directory - and when those attributes change, the entitlements that depend on them recompute without a ticket, a reminder or a review catching it later.
The capability composes with, rather than replaces, the suite's role model. RBAC and Governance carries the stable core - the birthright access that genuinely follows job function, plus requests, certification and segregation-of-duties rules. Dynamic policies handle the conditional layer above it: access that should exist only while an attribute holds. Because both read the same authoritative directory - fed by HR through lifecycle automation - the facts that drive policy are the facts the enterprise actually maintains, and provisioning executes the recalculated result outward through SCIM and connectors automatically.
What recalculation looks like operationally
- A policy grants an application entitlement to identities where, say, department and location attributes match defined values.
- HR records a transfer; lifecycle automation updates the directory attributes.
- The policy re-evaluates: entitlements tied to the old attribute values fall away as those tied to the new ones take effect - and provisioning propagates both directions to connected systems.
- The audit trail records the attribute change and every entitlement movement it caused, as a connected story.
The mover problem - historically the worst-governed lifecycle event, where access accumulates across every past role - becomes the system's best-handled case: the move is an attribute change, and the access recalculates.
Enterprise scenario
Consider an enterprise IT environment with a large field workforce where regional data access must follow current posting. Under static administration, every transfer was a two-ticket event - grant the new region, revoke the old - and the revoke ticket lost races constantly, leaving field staff with accumulating regional access their audits kept flagging. Expressed as one dynamic policy over the posting attribute, the entire class of work and the entire class of findings disappear together: postings change in HR, access follows, and the quarterly review confirms alignment instead of hunting misalignment.
Governance and audit implications
Attribute-based policy strengthens the governance chain at its weakest link: justification. Every dynamically granted entitlement carries a live, checkable reason - the attribute condition that currently holds - rather than a historical decision someone once made. Reviews shift from interrogating stale grants to validating policy logic, a far smaller and more meaningful surface. And least-privilege attestation, which frameworks in Tanflow's compliance mapping ask for in various vocabularies, gains its strongest form: access provably conditioned on current facts, recalculated the moment the facts moved.
Conclusion
Organisations move continuously; access administered by memory and ticket does not. Tanflow's dynamic policies close that gap by binding entitlements to the attributes that justify them - so when the secondment ends, the posting changes or the engagement expires, the access already knows. The role model keeps the stable core; the policy layer tracks the moving edge; and the drift that reviews used to mop up simply stops being produced.