AWS Partner Network (APN) Blog

Orca just-in-time access & AWS IAM Identity Center solve permission sprawl

By: Merin Eralil, Security Partner Solutions Architect – AWS
By: Ashleigh Lee, Senior Product Marketing Manager – Orca Security


Orca Security Logo
Orca Security
Orca-Security-APN-Blog-CTA-1

How can you maintain developer velocity across hundreds of accounts while enforcing least-privilege access? A contractor gets access for a 3-week engagement. A developer gets elevated privileges to debug a production issue. The continuous integration and continuous delivery (CI/CD) pipeline retains permissions from a sprint that ended months ago. How often is this type of access reviewed?

This is how permission sprawl grows. Just-in-time (JIT) access is emerging as the operational answer to permission sprawl, which is the accumulation of permanently assigned permissions spread across hundreds of identities. Orca Security’s integration with Amazon Web Services (AWS) IAM Identity Center gives organizations an operational path to address this.

The problem is accelerating: A 2026 SANS survey of over 500 security professionals found that 74% of organizations are already deploying AI agents or automations that require credentials or access permissions. According to the survey, this trend is doubling or tripling non-human identity (NHI) populations inside many enterprises.

When permissions are scoped and time-bound, the impact of a credential exposure drops significantly. Organizations that remove persistent, broad access reduce their risk, including in the event that credentials are obtained by an unauthorized party. The principle of least privilege has long been the right architectural answer. What’s been missing is the infrastructure that makes it operational at scale.

To help customers implement JIT access efficiently, Orca Security provides an integration with AWS IAM Identity Center. This post explores how the integration works and what it means for security and engineering teams operating at scale in the AWS Cloud.

Permission sprawl creates security gaps

Major compliance frameworks including System and Organization Controls 2 (SOC 2), Payment Card Industry Data Security Standard (PCI-DSS), ISO/IEC 27001, Federal Risk and Authorization Management Program (FedRAMP), and the Health Insurance Portability and Accountability Act (HIPAA) require the principle of least privilege.

There’s a critical difference between documenting a policy and enforcing it. Persistent access models shift the burden to humans: Someone has to remember to remove access after a project ends or a contractor offboards. The consequences are measurable:

  • Over-provisioned identities become dormant access risks. Credential abuse accounts for 22% of the incidents in the Verizon 2025 Data Breach Investigations Report, showing that threat actors are logging in, not breaking in.
  • Incident responders have more scope to contain when accounts with inadvertent access hold persistent, broad permissions.
  • Auditors ask for evidence that least privilege is enforced in practice. Persistent access models produce no automatic audit trail to demonstrate this.

Modern engineering compounds this further. Infrastructure-as-code has made spinning up resources trivial, but access governance hasn’t kept pace. Developers move fast, access gets provisioned for a sprint, and those permissions remain long after the work is done. This is the predictable outcome when access management depends on manual cleanup rather than built-in expiration.

The solution: JIT access

JIT makes least privilege operational by providing temporary, scoped access by default. No one has permanently assigned permissions. Instead, a user requests specific permissions for a defined time window, provides justification, receives approval, and access is automatically revoked when the window expires. Nothing to clean up. Nothing to forget.

The following screenshot shows the JIT access request interface in the Orca platform, where teams submit, track, and manage time-bound permission requests:

Figure 1: Orca platform dashboard displaying JIT access requests with requester details, permission sets, target accounts, approval status, and access duration.

Figure 1: JIT access in the Orca platform

For cloud environments built on AWS, this approach must work at the identity infrastructure layer. A bolt-on solution that approximates access control from outside the AWS environment can’t deliver the same enforcement.

AWS IAM Identity Center provides the programmatic APIs for creating and revoking account assignments, forming the foundation of JIT access patterns. Customers use these APIs, orchestrated through Orca Security, to implement temporary permission workflows. That’s the design principle behind Orca’s JIT access integration with AWS IAM Identity Center.

How it works: Orca’s AWS IAM Identity Center integration

Organizations implementing JIT access through Orca benefit from its direct integration with AWS IAM Identity Center. When Orca orchestrates a JIT request, it acts within the customer’s AWS environment.

It creates and revokes access assignments in AWS IAM Identity Center on the customer’s behalf. When a user requests access, the integration creates a time-bound assignment in AWS IAM Identity Center, then automatically revokes it when the window expires.

The following image shows how JIT access requests flow between the Orca solution and AWS IAM Identity Center:

Figure 2: Architecture diagram showing the flow of a JIT access request from the Orca platform through its JIT API and requests broker to AWS IAM Identity Center, which manages permission sets, SSO users, and account assignments within the customer’s AWS organization.

Figure 2: Architecture diagram showing how JIT AWS permissions are requested by Orca Security

The workflow is intentionally low friction for the requester. A team member submits an access request through the Orca solution or Slack specifying the required permission set, target AWS account, and duration for which access is needed. An administrator reviews and approves or denies the request. Upon approval, the requester receives a notification from Orca and an email with approver information and access details.

Orca then manages the full permission lifecycle, creating the temporary access assignment in AWS IAM Identity Center and automatically revoking it when the time window expires. Administrators can also revoke access manually before expiration. Every action is recorded in Orca’s audit logs.

To prevent conflicts of interest, Orca prevents self-approval: No one can approve their own request. This addresses one of the most common gaps in peer-reviewed access models.

Use cases include incident responders accessing a production account, developers debugging across accounts, and contractors needing scoped access for a sprint. In all cases, access is temporary by design.

The AWS IAM Identity Center integration: Scoped by design

One of the key architectural decisions in this integration is how Orca holds its own access to the AWS environment. The integration follows least-privilege principles by scoping Orca’s AWS permissions to only those required for JIT orchestration.

To orchestrate JIT requests, customers grant Orca a specific, defined set of AWS permissions. These aren’t broad administrative rights. They’re scoped to exactly what JIT requires, including:

  • Creating and deleting account assignments
  • Checking the status of assignment operations
  • Listing permission sets provisioned to accounts
  • Listing AWS IAM Identity Center instances and permission sets
  • Listing users in the Identity Store
  • Describing permission sets

This scoped permission model reflects the same least-privilege philosophy JIT is built on. Orca doesn’t get more access to your AWS environment than it needs to do the job. This matters both as a security property and as an architecture that customers can explain to their auditors.

To set up the integration, connect your AWS organization management account to Orca, or a delegated administrator account if that’s how your AWS IAM Identity Center is configured. After prerequisites are met, the enable JIT wizard in the Orca interface walks administrators through setup. Orca then handles the operational layer, processing requests, managing approvals, creating time-bound assignments in AWS IAM Identity Center, and revoking them automatically when the window closes.

Complementing AWS security services

This JIT pattern complements AWS security services. AWS IAM Access Analyzer identifies unused permissions, and AWS CloudTrail logs all API activity. JIT access solutions complement these services by removing permanently assigned permissions. Organizations can correlate Orca’s audit logs with AWS CloudTrail events for end-to-end visibility into who accessed what, when, and why.

For teams using AWS Security Hub, JIT access means fewer findings related to over-provisioned or unused permissions because those permissions no longer exist to be flagged.

Automated compliance evidence

Compliance frameworks require least-privilege enforcement. Auditors are moving beyond policy documentation and asking for evidence. JIT access automatically generates audit trails showing the full lifecycle of each access event. This evidence supports SOC 2, ISO 27001, FedRAMP, and HIPAA certifications.

Each step in the access lifecycle is logged in Orca’s Audit Logs. For organizations pursuing or maintaining compliance certifications, that audit trail has a real value beyond the security posture improvement itself. It converts a manual attestation exercise into a queryable record.

What this means for security leaders and engineering teams

This integration delivers different value depending on your role. For CISOs and security directors, JIT access closes the gap between stated policy and actual enforcement. It makes least privilege operationally sustainable across large AWS environments without requiring a dedicated team to manually audit permissions.

For platform and DevSecOps teams, security stops being a separate step. The workflow handles scoping, approval, and revocation without changing how engineers request access. The security overhead gets absorbed by the system.

That’s the case worth making to any executive team: JIT doesn’t slow access down. It makes access defensible.

Get started

Orca Security is available through the AWS Marketplace. To explore how Orca’s JIT access integration can help your organization enforce least privilege at scale across your AWS environment, visit the AWS Marketplace listing or contact Orca Security for a demo.
Connect with Orca Security


Orca Security – AWS Partner spotlight

Orca Security is an AWS Specialization Partner Partner that delivers a unified cloud security experience that helps organizations identify, prioritize, and remediate risk across their cloud environments, code, and AI.
Contact Orca Security | Partner Overview | AWS Marketplace