AWS says access to an account through IAM Identity Center depends on both the account assignment and the level of permissions granted to the user. Authentication at the access portal is a different control from authorization inside the account. AWS IAM Identity Center access guidance makes that distinction explicit. A useful security assessment follows the whole path from workforce identity to the actual account action.
Quick answer. An AWS IAM Identity Center permission set assessment should map each selected group or user to its assigned accounts, permission sets, generated roles, account-local policies and allowed actions. Test a few approved and forbidden decisions with customer-owned test identities, preserve policy and CloudTrail evidence, and record session behavior separately. The scope concerns customer configuration and customer-owned assets under AWS's testing policy; it does not authorize probing the IAM Identity Center service itself.
The commercial question is narrower than "is AWS SSO secure?" A mid-market company may have one security team and several AWS accounts. An enterprise may have many accounts, different application owners and separate identity, platform and security teams. In either case, a buyer needs to know whether the intended people can reach the intended accounts with the intended authority, and whether a change to a group, policy or permission set leaves an unexpected path open. A generic cloud scan cannot settle those decisions without a signed expected-access map.
The access path a buyer should purchase
The assessment unit is an access path, not an isolated permission-set name. AWS describes a permission set as a maintained template of IAM policies that is assigned to a user or group in one or more accounts. The assignment creates an IAM Identity Center-controlled role in each target account. AWS permission-set documentation The buyer should therefore ask for a row for every representative combination of identity, account and permission set that matters to the business.
Figure 1: An editorial evidence path for a selected workforce access decision. Source: AWS, IAM Identity Center access guidance.
Boundary | Buyer-approved expectation | Safe observation | Evidence to keep | Owner |
|---|---|---|---|---|
Source identity | Named test user has the intended source group | Confirm group provisioning and membership in the identity source and IAM Identity Center | Group identifiers and sync state, without personal data | Identity team |
Account assignment | Group reaches only selected AWS accounts | Compare a permitted account with a deliberately unassigned account | Assignment export and portal or CLI result | Cloud platform team |
Permission set | Selected account role has the intended policy bundle | Inspect attached managed, customer-managed and inline policies | Permission-set version and target account | Cloud security team |
Account-local policy | A same-named policy does not silently grant a different result | Compare effective policy documents in chosen accounts | Policy document hashes and the resulting decision | Account owner |
Resource boundary | Read or change action applies only to approved resource | Use a harmless read case and a denied neighboring resource | Action, resource, context and sanitized response | Resource owner |
Session | Access change has the expected effect on new and existing sessions | Observe new-session denial and document the existing-session expiry boundary | Session configuration and timestamped result | Identity and response teams |
Logging | The decision can be reconstructed | Correlate account activity and IAM Identity Center management events | Event IDs, time, account and role | Security operations |
The table is a procurement worksheet. It does not describe a universal AWS configuration or imply that every control can be safely exercised in production. The business owner first signs off on allowed and forbidden outcomes. The tester then collects only the minimum data needed to observe those outcomes.
Separate sign-in, assignment and account authority
An external identity provider can authenticate a workforce user, but that does not answer which AWS accounts the user can enter. AWS says external IdP users and groups must be provisioned into IAM Identity Center before account or application assignments can be made, and IAM Identity Center grants resource access based on its configured policies. AWS external IdP documentation The first handoff in scope is therefore the mapping between the corporate group and the group that receives an AWS assignment.
Ask the identity owner for a controlled pair of test personas. One belongs to an approved workforce group; the other does not. Give both known, non-sensitive identities. Then compare the account list each receives after provisioning and sync. The observation should include the source group, IAM Identity Center group, account ID, permission-set name and timestamp. A missing account might reflect a delayed sync, a missing assignment or an intentional denial. A visible account does not prove that every operation inside it is appropriate.
Some assessments stop after checking that the portal tile appears. That produces weak evidence. The tile reflects a route into an account, while the generated role and its policies determine what happens next. AWS's access guidance specifically treats assignment and level of permission as separate factors. Require both in the statement of work. If the buyer uses account access manager or direct IAM roles in addition to permission sets, list those as a separate path rather than assuming the permission-set export covers them.
Trace the policy that actually governs an account
AWS permits AWS managed policies, customer-managed policies, inline policies and permissions boundaries within permission sets. AWS permission-set documentation A reviewer needs to identify each type for the selected role. Looking only at the permission-set display name can miss a broad managed policy or an account-local policy with the expected name and a different body.
The account-local case deserves a specific buyer test. AWS states that a customer-managed policy referenced in a permission set must exist in each target account with a matching name and path, but the permissions it grants do not have to match across accounts. AWS policy guidance An organization can intend a uniform "Analyst" permission set and still get different authority if the account-local policies differ. Compare the policy documents for two representative accounts and record the action and resource consequences. A policy hash, account ID and policy version help the owner reproduce the result later.
Do not label every difference a vulnerability. A production account may deliberately be narrower than development. A finance account may intentionally exclude a service used elsewhere. The buyer needs a written expected-access statement for each account class. The assessor should call a difference a finding only when it violates that approved design or opens a meaningful path to data or change authority.
Use a bounded decision table rather than a vague "least privilege" observation:
Persona and account | Action and resource | Expected | Observed | Policy explanation | Decision owner |
|---|---|---|---|---|---|
Approved analyst, analytics account | Read a synthetic report object | Allow | Record during test | Named permission-set and resource policy | Data owner |
Same analyst, finance account | Read a synthetic finance object | Deny | Record during test | No assignment or explicit resource boundary | Finance owner |
Release engineer, production account | Inspect a named deployment resource | Allow | Record during test | Scoped role policy | Platform owner |
Release engineer, production account | Change an unrelated security control | Deny | Record during test | Policy and boundary | Security owner |
These are fictional examples. The final assessment should replace them with authorized test accounts and synthetic or otherwise safe resources. It should never include a real customer name, real business record or live credential in the report excerpt that becomes public.
Use simulation and live evidence for different purposes
The IAM policy simulator can evaluate identity-based policies, permissions boundaries, service control policies and supplied resource-based policies without sending a real request to the AWS service. AWS says each simulation returns an allow or deny decision, but warns that results can differ from a live environment. AWS policy simulator guide This makes simulation a useful preflight tool, not a stand-in for every observed authorization boundary.
Start with the agreed action, resource and context values. A policy review can identify an obvious broad grant without exercising it. The simulator can then check selected allow and deny cases and explain which policy produced a result. For any case that must be validated live, choose a low-impact read operation or a controlled synthetic resource. Record the actual role session and response. Do not convert a simulator-only result into a statement that an application exposed real data.
Context matters. A request might depend on resource tags, requested region, network conditions, organization policy or a resource policy. AWS notes that the simulator does not use real production context values automatically for every key and can differ from live behavior for advanced configurations. AWS policy simulator guide The test record should list the inputs provided to the simulation and state which controls were not represented. A report that says "allowed by simulator" without those inputs can mislead a remediation owner.
The live test boundary must be narrow. Obtain written permission for the customer-owned account and resource, use the agreed identity and time window, set a request budget and have a stop contact. AWS's customer testing policy names permitted services, prohibits testing AWS's own services and restricts certain activities. AWS Customer Support Policy for Penetration Testing For this topic, a configuration and entitlement assessment is the sensible baseline. Testing an AWS-managed sign-in endpoint or control-plane service is outside that baseline.
Treat session behavior as an acceptance question
An access review that checks only new sign-ins misses active role sessions. AWS documents that IAM role sessions created from permission sets operate independently after establishment and can continue for the configured duration even if the original sign-in session ends. It also distinguishes the portal session from the role session. AWS session guidance The buyer should decide what "access revoked" means in the acceptance criteria: no new role sessions, no portal access, and a known expiration or response method for existing sessions.
Test this with a disposable identity and a low-risk account. Record the time of assignment removal, whether a new session can be started, the configured role-session duration and the status of an already established session. Do not infer that removing a group instantly invalidates every credential already issued. AWS's session reference says existing IAM role sessions can persist until their configured expiry, even while new access changes take effect. AWS session behavior If the organization needs emergency revocation, ask the response owner to demonstrate the documented process in an approved lab or tabletop, not by disrupting a real employee.
The SOW should distinguish this session test from a full incident-response exercise. A normal permission review can document duration and revocation design. A response drill may require a change window, a disposable account and rollback plan. Procurement can buy one or both, but should not assume the former proves the latter.
Keep an evidence chain that a security team can use
AWS CloudTrail records IAM Identity Center API activity from the console and APIs, and AWS documents sign-in events separately. The records can help identify who made a management request, when, and from where. AWS IAM Identity Center logging A useful deliverable links a test decision to the relevant assignment state, generated role, policy version, request and event. It does not paste a full identity-store export into the final report.
For each selected row, require five pieces of evidence: the expected outcome signed by the resource owner, the identity and account mapping, the governing policy material, the bounded observation, and an event or log reference. The report should separate observed behavior from root-cause interpretation. A denied request may be caused by no assignment, by an identity policy, by a boundary, by an organization policy or by a resource policy. The owner needs to know which control actually governed the decision.
When the organization cannot supply an event, record that as an evidence gap. It may reflect logging retention or access limits rather than a failed authorization control. The remediation route differs. The report should name the logging owner and say whether the relevant event was never captured, was captured but not provided, or was unavailable to the assessor.
An executive summary can state the outcome in business terms: which workforce groups could reach the selected accounts, whether the intended account actions were bounded, where policy drift was found, and which session or logging questions remain open. The technical appendix should retain exact account identifiers, policy references and sanitized requests under the customer's own access controls. Public marketing copy does not need those identifiers.
How to scope a representative engagement
Start with the account inventory, but sample by risk and access pattern rather than selecting only the easiest accounts. Include an account with sensitive data, an account used for production delivery, one development or sandbox account and any management path that the customer authorizes. Select permission sets with broad or change-capable authority and one narrow baseline. Note direct assignments and group assignments separately. The sample size depends on architecture and budget; the SOW should name the exact coverage rather than promise an undefined "all AWS access" conclusion.
The identity team should supply the source IdP, provisioning method, test group, current assignment list and expected sync window. The cloud team should supply account IDs, permission-set definitions, generated-role references and account-local policy documents. The business owner should approve allowed and denied actions. Security operations should identify the relevant CloudTrail views and how evidence can be shared safely. This division of labor prevents a pentest provider from guessing business entitlement intent.
Ask the assessor to declare any path it cannot test. For example, an external IdP group may be provisioned but not available for controlled membership changes; a customer-managed policy may be unavailable in an account; or a production action may be too disruptive. The assessor can still document configuration and simulation results, but the final report must label them as such. A clear limitation is more useful than an apparent pass based on the wrong identity or an incomplete account sample.
The test window should include both observation and a planned retest. When a finding is fixed, repeat the original persona, account, action and resource. If a customer-managed policy changed, compare its new document in every sampled account where the permission set is assigned. If group membership changed, verify the new-session result and document what happens to existing sessions. A retest that checks only the policy text cannot prove that the effective path was closed.
What the statement of work should name
A buyer-ready SOW can describe the selected IAM Identity Center instance, source identity system, approved test identities, AWS account IDs, permission sets, role paths, target resources, expected allow and deny decisions, test methods, request limits, evidence handling and retest. Include the account owner, identity owner and response contact. State whether the work includes only configuration review and simulation, or also bounded activity against customer-owned workloads permitted by AWS policy.
The deliverables should be explicit: an access-path inventory for the sample, a decision matrix, confirmed findings with affected account and policy, prioritized remediation, a session-behavior note, logging evidence and retest records. The report should identify out-of-scope accounts and any use of account access manager or direct IAM roles that was excluded. These details let a buyer compare two proposals on coverage rather than a generic promise to "assess AWS IAM."
Ask prospective testers how they will handle three situations. First, two accounts use the same customer-managed policy name but contain different policy bodies. Second, a user is removed from a group while a role session is active. Third, the simulator allows an action but a bounded live request is denied. A useful answer should name the evidence, likely control owners and the limit of each observation. It should not require a production-changing exploit to prove a basic entitlement mismatch.
For a broader program, connect this engagement to cloud penetration testing services when customer-owned workloads and cross-account paths are also in scope. The enterprise identity test matrix provides a companion way to define identity decisions, while the Microsoft Entra workload federation test plan addresses a different nonhuman trust path. This post's unit remains workforce assignment and effective AWS account authority.
Where Stingrai fits
Stingrai is a CREST-accredited penetration testing company with human-led cloud and application testing for mid-market and enterprise teams. For this engagement, Stingrai can scope the customer-owned AWS identities, accounts and workloads, compare authorized and unauthorized paths, document confirmed findings with reproducible evidence, and retest remediated controls. Stingrai's cloud testing service describes its AWS, Azure and GCP work. The buyer remains the owner of its access design and AWS account configuration.
The most useful first conversation is about a small set of high-impact access decisions, not a request for every permission set in the organization. Bring the account inventory, a representative assignment export, the identity and platform owners, and examples of actions that must be allowed or denied. That is enough to shape a proposal with a real evidence matrix and clear authorization boundary.
Frequently Asked Questions
What should an AWS IAM Identity Center permission set assessment cover?
It should cover selected source identities, account assignments, permission sets, generated roles, account-local policy documents, allowed and denied actions, session behavior and event evidence. The SOW should name the exact accounts and decisions in scope.
Is checking the permission-set name enough?
No. A permission set can contain several policy types, and a customer-managed policy with the same name can grant different permissions in different accounts. Compare the effective policy material and the observed decision for each selected account.
Does removing a group assignment end every active AWS role session?
No. AWS says existing IAM role sessions can continue until their configured duration ends, even after access changes prevent new sessions. Document the expected revocation behavior and use an approved response procedure when urgent termination matters.
Can a tester penetration-test the IAM Identity Center service?
AWS's customer testing policy does not permit testing AWS's own services. A buyer can scope a review of its own assignments, policies and customer-owned assets, and must apply AWS's current policy to any active test method.
Related reading
Talk to Stingrai
Share the accounts, workforce groups and expected access decisions you want examined. Get a Quote or book a free discovery call to define a bounded assessment and its evidence.
