A completed access review is not the same thing as removed access. If you care about governance, compliance, and operational control, you need access reviews that do more than record a revoke decision. You need revocation tracking that proves the change reached the authoritative target—or shows a visible, owned exception when it did not.
That distinction matters for CIOs and Heads of IT because the risk does not end when a reviewer clicks revoke. A campaign can close, a task can complete, and an approval record can exist while access still remains in the source system, in a nested group path, or behind a manual remediation step. The control is only complete when you can account for the actual state change.
Citadel Identity360, from Astranova Labs, closes that gap. Reviews, AI-assisted decision support, identity-graph context, lifecycle orchestration, verify-after-write, and exportable audit evidence sit in one governance model—so a revoke decision becomes verified removal, not a process status that stops at attestation.
The real completion standard for access reviews
The standard Citadel enforces is simple: a review is finished only when revoked access is actually removed, or when an owned exception is documented and visible.
That means the workflow must do six things well. It must assemble a complete, attributable access population. It must send each entitlement to the right reviewer—an application owner for resource-specific access or a manager for employment-context decisions. It must provide useful decision support, not opaque automation. It must handle silence through reminders or escalation. It must translate a revoke decision into execution. And it must verify the resulting state at the target system.
Anything less creates false confidence. A submitted provisioning request is not removal. A closed campaign is not removal. A finished task is not removal. Those are process states, not proof of the target-side outcome.
Citadel is built around that filter. The platform shows the chain from decision to confirmed removal across the applications you govern—so you complete governance, not just document it.
Application-owner reviews start from a complete population
Strong governance starts with the right population and the right reviewer.
Citadel reconciles identities, accounts, applications, roles, and entitlements before a campaign starts. Missing identities, disconnected applications, and indirect role or group paths can make a campaign look complete while the control is still incomplete. For resource-specific access, the reviewer is usually someone who understands the application and its permissions. For employment-context decisions, a manager is often the better choice.
The useful test is whether the reviewer can see the entitlement, the access path, and the identity context. Citadel’s identity graph brings identities, roles, applications, and permissions into one view—so reviewers see meaning, not only a technical permission string, and disconnected applications stay in the population instead of silently dropping out.
Governance basics that often fail at the edges are first-class in Citadel: fallback owners for vacant positions, delegation tracking, and prevention of self-approval for privileged access. Those details matter because access reviews fail at the edges more often than at the center—and Citadel keeps those edges governed.
Intelligent recommendations support judgment—they do not replace it
Decision support is valuable only when it is explainable enough for a reviewer to challenge.
Citadel surfaces visible reasons and risk context for retain or revoke recommendations. Sensitivity of the entitlement, actual usage where available, unusual peer access, role conflicts, contractor end dates, and segregation-of-duties concerns are all useful inputs. The reviewer sees the platform’s suggestion, makes an actual decision, and can override it with a rationale.
That separation is intentional. Recommendation, human decision, and override rationale stay distinct in the audit trail—so the reviewer is never a rubber stamp. Citadel does not do automatic attestation. It delivers accountable human judgment with strong support: pre-populated AI-generated recommendations, SoD and risk scoring, and clear override handling.
For a decision-stage buyer, that is the right standard. A faster review that cannot be defended later is not a better control—and Citadel keeps the defense intact.
Deadlines and escalation keep undecided items visible
Silence is never treated as closure.
Citadel review workflows define campaign duration, reminders, fallback reviewers, escalation recipients, and the disposition of undecided items. If a privileged-access review sits unanswered, it does not quietly disappear because the campaign expired. It remains visible, attributable, and governed by policy.
This is one of the clearest places where revocation tracking separates Citadel from shallow workflow tools. You are not only asking whether reviewers can make decisions. You are asking whether the system can handle nonresponse in a controlled way—and Citadel’s escalation mechanisms, delegated approvals, and approaching-expiry alerts are built for that policy-controlled end state.
Put an unavailable owner on a high-risk item and Citadel keeps the item alive: alert, reassign, escalate, and preserve the exception. It does not mark the campaign complete and move on.
Remediation handoff is where Citadel keeps control
Once a revoke decision is made, the workflow must carry that decision into execution.
This is where many access programs lose credibility—and where Citadel’s integrated lifecycle and provisioning orchestration are decisive. The record shows a revoke, and Citadel drives the actual entitlement change: connector write for connected applications, named accountability and evidence for disconnected or legacy ones. If a connector fails or a task is still open, that state stays visible instead of creating the appearance of completion without the substance of removal.
At minimum, the workflow captures the identity, application, entitlement, reason, reviewer, decision time, executor, and any task or change identifier. For connected applications, Citadel inspects the deprovisioning action and any retry or failure. For disconnected or legacy applications, named accountability and evidence of the actual change replace the weak pattern of “someone created a task.”
Scope matches the access path. Removing a direct entitlement is not the same as removing a role assignment, changing a role membership rule, removing a nested-group path, disabling an account, or invalidating a credential or session. Citadel ties review outcomes to the correct remediation path inside the same governance model—so attestation is never the end of the story.
Connector breadth matters here. Citadel covers REST, SOAP, SCIM, LDAP, JDBC, flat files, SFTP, scheduled batch, mainframe, and custom paths—no-code-first configuration, with roughly 400 hours of included customization for estate-specific mappings. That is how decision→removal stays real across hybrid estates, not only for a short list of cloud SaaS apps.
Proof of removal decides the platform—and Citadel verifies after every write
The decisive test is verification against the target’s resulting access state.
Citadel’s verify-after-write step closes that gap. You get a post-change read-back showing that the specific entitlement was removed, reconciled with the original review item, and kept in the full chain: decision, rationale, delegation, timestamps, execution response, failed attempts, retry history, and exception disposition.
This is the evidence hierarchy that actually matters: decision and rationale, remediation request and executor, connector or administrator action, target-side event or read-back, and exception closure. Citadel preserves every layer as exportable audit evidence.
A task marked complete without target-state confirmation is weaker evidence. A completed campaign without removal verification is weaker evidence. A successful revoke record with no proof against the authoritative target is weaker evidence. Citadel does not treat those as enough.
Decision-to-verified-removal time is tracked separately from reviewer completion time. Those are not the same metric—and Citadel does not pretend they are.
Why competitors stop short—and where Citadel closes the loop
Only platforms that combine certification with connected provisioning or accountable manual remediation can close the loop, and only for the systems they actually govern. Citadel is built to do both across the estate you run.
Microsoft Entra access reviews can apply denials to supported group memberships or application assignments. With auto-apply enabled, changes apply when the review completes or is stopped early. Without it, an administrator applies the results later. That is useful inside Entra’s supported surface—but it is narrower than removing access inside every connected application. Nested groups, on-premises sources, and group-derived application assignments introduce documented limitations. Citadel’s connector breadth and verify-after-write are designed for the hybrid reality those limitations leave open.
SailPoint Identity Security Cloud documents automatic removal for direct-connect sources, manual-removal tasks for some other sources, a Campaign Remediation Status Report, and provisioning activity details. Administrators are still instructed to verify remediation themselves. That is a more explicit remediation story than Entra—but it still leaves the buyer stitching source type, manual path, and target-side state together. Citadel keeps decision, execution, verification, and evidence in one model instead of pushing verification back onto the administrator as an afterthought.
Citadel Identity360 is the platform for buyers who want reviews, AI-assisted recommendations, identity context, lifecycle orchestration, and audit reporting in one place—including human and non-human access under one governance model. NHI and AI-agent controls cover MCP registration, accountable ownership, tool-level authorization, and a kill switch. Citadel’s AI governance also produces a governed MCP access configuration file that other agent platforms and MCP clients can consume. Contractor lifecycle—end dates, sponsors, and timed removal—feeds the same review and revocation path as employees. The question is not whether Citadel has the broadest claim. Citadel demonstrates the complete path from decision to verified removal.
That is the practical buying standard. Do not compare campaign interfaces in isolation. Compare whether the platform can prove revocation through to completion. Citadel can.
What to validate in a Citadel demonstration
Use a live demonstration to test the control, not the slide deck.
Ask to see:
- a complete review population with ownership and source of assignment in the identity graph
- an application-owner review and a manager review
- an AI-assisted recommendation with visible rationale and SoD / risk context
- a high-risk item with reminders and escalation
- a revoke decision for a direct entitlement
- one indirect role or group grant
- one disconnected or legacy application
- a failed removal with retry and owned exception
- target-side confirmation via verify-after-write
- exportable audit evidence for the full decision→removal chain
When Citadel shows the failure path, the retry path, and the proof of removal, you know the workflow actually completes. That is the proof-of-value standard—and it is the standard Citadel is built to meet.
To put verified removal at the center of your review program, request a Citadel Identity360 demonstration against your own applications—including a failed removal and a disconnected source. That is how you judge whether a platform truly closes the loop.
FAQ
Does a completed campaign mean access is gone?
No. A completed campaign means the review workflow finished. Access may still be pending, failed, unsupported, or waiting on manual remediation. Citadel treats verified target-side removal—or a visible owned exception—as the real completion standard.
Why is a closed task not enough?
Because a task only proves handoff or work status. It does not prove the entitlement was removed from the target system. Citadel’s verify-after-write step requires that proof before the control is closed.
Can AI recommendations make the decision?
They should not. Citadel uses them as decision support. Recommendation, human decision, and override rationale stay separate in the audit trail.
What should I verify before I trust revocation tracking?
Verify the target-side state, not just the workflow status. You want evidence that the specific entitlement was removed, plus a record of any failure, retry, or exception. Citadel keeps that full chain as exportable audit evidence.
Why choose Citadel for revocation tracking?
Because attestation without verified removal is incomplete governance. Citadel Identity360 combines access reviews, identity-graph context, lifecycle orchestration, broad connectors, SoD and risk scoring, contractor and NHI/AI-agent controls, verify-after-write, and exportable evidence—so decision→verified removal is the default path, not an optional follow-up.
If you want access reviews that stand up to audit and operational scrutiny, make verified removal the standard. Citadel Identity360 is the platform that demonstrates that standard—from reviewer decision through connector or fulfillment execution to confirmed target-side state.