Migrating from Azure Identity Governance to an Okta plus AWS IAM Identity Center stack isn’t just a platform swap — it’s a change in how the identity layer interacts with access reviews, and the automation approaches that worked on Azure may need to be rebuilt differently on the new stack. Here’s how access reviews work across Okta and AWS IAM Identity Center natively, where the gaps are, and what automation approaches teams are actually using.

What Does Access Review Look Like Natively in Okta? Okta’s native governance capabilities are primarily authentication-focused. Okta manages how users authenticate to applications — SSO configuration, MFA policies, conditional access, application assignments. It doesn’t have a dedicated access certification module in the same way that Azure Identity Governance does. What Okta provides that’s relevant to access reviews: Application assignments: Okta shows you which users are assigned to which applications, and you can export this data. Group memberships: Okta groups control application access, and group membership reports are exportable. Access policies: Okta’s access policy engine shows you which policies apply to which users, which is useful context for reviews. What Okta doesn’t provide natively: A structured certification campaign workflow. A mechanism to assign review tasks to specific reviewers and track their responses. An audit trail of review decisions with timestamps. Automated deprovisioning triggered by reviewer revocation decisions. The practical implication: Okta gives you the data for access reviews, but it doesn’t give you the process. Teams that try to run access reviews using Okta exports alone end up with the spreadsheet workflow — export the user list, distribute it, collect responses — which has the evidence and accountability limitations that compliance audits consistently surface.

What Does Access Review Look Like Natively in AWS IAM Identity Center? AWS IAM Identity Center (formerly AWS SSO) manages access to AWS accounts and services within an AWS Organization. The native capabilities relevant to access reviews: Permission sets: IAM Identity Center uses permission sets to define what access users have within AWS accounts. You can see which users have which permission sets assigned, and which accounts those permission sets apply to. Account assignments: The mapping of users and groups to AWS accounts through permission sets is visible and exportable. AWS access analyzer: This tool surfaces over-privileged policies and unused access in IAM, which is useful for identifying remediation candidates. What IAM Identity Center doesn’t provide natively: A certification workflow. Automated reviewer assignment. An audit trail of access decisions in a format suitable for compliance evidence. Integration with the broader application estate outside AWS. The AWS IAM layer — as distinct from IAM Identity Center — adds significant complexity. IAM roles, policies, permission boundaries, and trust relationships in individual AWS accounts are separate from the IAM Identity Center permission sets, and effective access to AWS resources is the combination of both. A user who is assigned a permission set in IAM Identity Center may have additional permissions through IAM roles in specific accounts, or may be able to assume roles that expand their effective access beyond what the IAM Identity Center assignment suggests. Access reviews that only look at IAM Identity Center assignments without examining the IAM layer in underlying accounts are reviewing an incomplete picture of actual AWS access.

What Were You Actually Using in Azure Identity Governance? Azure Identity Governance — specifically Entitlement Management and Access Reviews — is one of the more fully featured native governance capabilities in any identity platform. Specifically: Entitlement Management lets you define access packages (bundles of resources — groups, SharePoint sites, application assignments) and manage the lifecycle of who has access to each package. Access Reviews in Entra ID let you run structured certification campaigns: assign reviewers, set deadlines, require decisions for each access record, generate non-editable reports at campaign close. These capabilities don’t have direct equivalents in Okta and IAM Identity Center. The migration you’re describing means moving from a platform with purpose-built access review functionality to two platforms that handle different parts of the authentication and authorization stack without either providing the certification workflow you were using. The honest answer: you’ll need a third-party governance layer to replicate the access review capabilities you had in Azure Identity Governance, unless you’re comfortable with a significant step back in review process maturity.

What Automation Approaches Are Teams Using? Approach 1: Governance Platform as the Review Layer This is the most common approach for organizations that want to maintain access review quality while migrating from Azure to an Okta/AWS stack. A dedicated governance platform — separate from both Okta and AWS IAM Identity Center — handles the certification workflow. The governance platform pulls user and access data from Okta (application assignments, group memberships), AWS IAM Identity Center (permission set assignments, account assignments), AWS IAM (role assignments, policy attachments), and any other connected applications. The review campaign runs in the governance platform: reviewers are assigned, tasks are distributed, decisions are tracked, deadlines are enforced, and deprovisioning is executed automatically for revocation decisions. The evidence package — non-editable, timestamped, capturing all reviewer decisions and remediation confirmations — is generated by the governance platform. This approach gives you a review process that’s independent of any specific identity platform, which means the process doesn’t need to be rebuilt each time the underlying IdP changes. The tradeoff is an additional platform to manage, but for organizations with serious compliance requirements it’s usually the right architectural choice. Approach 2: Okta Workflows for Lightweight Automation Okta Workflows — Okta’s no-code automation layer — can be used to build review processes on top of Okta’s data. A workflow can export a list of application assignments, send review tasks to managers via email or Slack, collect responses, and execute deprovisioning actions based on those responses. This is more structured than a spreadsheet workflow and can produce a reasonable audit trail within Okta’s event log. The limitations: Okta Workflows are constrained to Okta’s data model. They can’t natively pull AWS IAM Identity Center data or AWS IAM data, which means reviews built on Workflows are limited to Okta-managed access. The audit evidence produced by a Workflows-based review process is in Okta’s event log format, which may or may not satisfy what your auditors expect. Building and maintaining a Workflows-based review process requires ongoing development work as requirements change. This approach is reasonable for smaller organizations or those with limited compliance requirements. It’s not suitable for organizations that need SOX-level access review evidence for AWS-managed access. Approach 3: Custom Automation via API Organizations with engineering resources sometimes build custom review automation using the Okta API and AWS APIs directly. The Okta API provides full access to user data, application assignments, and group memberships. The AWS IAM Identity Center API provides access to permission set assignments and account assignments. A custom solution can pull from both, build a review interface, track decisions, and execute deprovisioning actions. The challenge is everything that comes after the initial build: maintaining the automation as APIs change, adding new applications and access types, generating evidence in formats that evolve with auditor requirements, and ensuring the solution remains reliable as the organization scales. Custom automation is often the path organizations start with and then replace with a purpose-built governance platform when the maintenance burden becomes unsustainable.

What Specifically to Watch For in an Okta/AWS Transition The AWS IAM Gap The most significant risk in a transition to Okta/AWS IAM Identity Center is the IAM layer in underlying AWS accounts. Organizations that implement IAM Identity Center without auditing existing IAM configurations often discover that users have IAM permissions in individual accounts that weren’t visible in the Identity Center layer. The access review process needs to include both IAM Identity Center assignments and IAM-level permissions in underlying accounts to produce a complete picture. Non-SSO Applications in the Okta Estate Okta’s application catalog includes applications that are managed through SCIM provisioning, applications that use SAML/OIDC SSO without SCIM, and bookmarked apps that are just links in the Okta dashboard without any provisioning integration. Access reviews that treat all Okta-assigned applications as equivalent miss the important distinction: a SCIM-provisioned application is actually deprovisioned when you remove it in Okta; a bookmarked app isn’t. The review process needs to account for this distinction. Evidence Format Requirements If you’re migrating from Azure Identity Governance, your existing audit evidence is in Azure’s report format. Your auditors may have expectations based on that format, and the evidence from a new review process may look different. Establish what format your auditors will accept before the first post-migration review cycle, not after.