IAM Temporary Delegation to the rescue
Imagine your customer clicks a button and your product is in their hands, adding value. IAM Temporary Delegation can help you realise that vision.
At Cloudsoft, we've spent years helping AWS Partners navigate the complexities of cross-account access. We often access customer environments securely using IAM roles. We even have a polished document explaining what role we need, what it can do and why we need it. We provide a quick create link to drop the customer directly into CloudFormation to deploy our stack, reducing the number of steps to take.
For example, a link similar to this: https://console.aws.amazon.com/cloudformation/home?region=eu-west-2#/stacks/quickcreate?templateURL=https://your-template-bucket/iam-role-template.yaml&stackName=SensibleNameForYourCustomerToRecognise).
This works for us quite well and is relatively easy for a customer to follow. We send over a PDF, they log into their AWS, click the link in the PDF and create the role. However, this is done after a call, over email, and we need details back from the customer so we can complete the process.
We are helping numerous ISVs refine their product-led growth (PLG) strategies, and a key part of that is the customer's journey. Providing a seamless, frictionless experience is paramount, as we recognise that every customer's initial interaction with your product is critical to long-term success.
The ability to deploy your product into a customer environment, which depends on permissions to do so, is a potential point of friction.
Today, many will have guides, a CloudFormation template or Terraform configs, and the customer is left to deploy these. Even if you use a quick create link, the customer still needs to return information to allow you to complete the process and have your product up and running. If there are any issues, the instructions were not clear, or the customer misconfigured things, the drop-off rate for adoption increases.
This is where IAM Temporary Delegation comes to the rescue. AWS announced IAM Temporary Delegation around re:Invent 2025.
What IAM temporary delegation actually is
IAM Temporary Delegation is an IAM capability that lets AWS Partners request short-lived, scoped permissions in a customer's AWS account through a guided, AWS-native workflow. Here's the flow:
- Partner initiates a request - Your application calls the CreateDelegationRequest API, specifying a pre-registered policy template that defines what permissions you need and for how long.
- Customer reviews in the AWS Console - The customer is redirected to the IAM console where AWS itself displays the exact permissions being requested. No ambiguity, no documentation.
- Customer approves - With a single click, the customer approves the delegation. AWS releases an exchange token via SNS.
- Partner receives temporary credentials - You call GetDelegatedAccessToken to exchange the token for temporary AWS credentials.
- Partner configures resources - You use those credentials to set up whatever your product needs - IAM roles, S3 buckets, EventBridge rules, whatever - then the credentials expire automatically.
The entire customer experience is: click a button in your product > review permissions in the AWS Console > approve > done. One click to value.
Why this matters for a frictionless experience
Reduced time-to-value
The single biggest metric in PLG is time-to-value. How quickly does a new user experience the benefit of your product? With traditional IAM role setup, you're looking at minutes to hours depending on the customer's familiarity with IAM. With IAM Temporary Delegation, it's seconds.
Lower drop-off rates
Every context switch - between your docs, the AWS Console, your application, back to the console - is a drop-off point. IAM Temporary Delegation eliminates all of them. The customer never leaves a guided flow.
Trust through transparency
Customers see the exact permissions in the AWS Console, presented by AWS itself. This isn't your documentation claiming you only need read access to Cost Explorer - it's AWS showing precisely what actions on what resources for how long. This builds trust with security-conscious customers who might otherwise stall your onboarding in a security review.
Built-in governance
The capability includes administrator approval workflows. In organisations with stricter controls, users can submit delegation requests for admin review with business justification. This means your product can serve both developer-led sign-ups and enterprise procurement processes with the same integration.
Auditability by default
All actions performed using delegated credentials are logged in AWS CloudTrail in the customer's account. Full visibility, no additional instrumentation required.
Temporary access vs. long-term roles
You can have both.
A common pattern is to use temporary delegation for the setup phase and create a long-term IAM role during that setup. The temporary credentials last up to an hour - enough to provision whatever your product needs for ongoing operation.
When creating long-term roles through this mechanism, AWS enforces a permissions boundary that you register during onboarding. This boundary caps the maximum permissions the role can ever have, giving customers assurance that even if your product's role policy changes in future, it can never exceed what they originally approved.
This is a significant improvement over the traditional pattern where customers create roles manually and may not attach boundaries, or where permissions drift over time without visibility.
How to get started as an ISV
Prerequisites
- You must be enrolled in the AWS ISV Accelerate programme
- Your product must be listed in AWS Marketplace with a "Deployed on AWS" badge
Integration steps
- Define your policy templates - Determine the minimum permissions your product needs for onboarding. Think least privilege. AWS will review these.
- Register a permissions boundary if creating long-term roles - Define the maximum permissions any role you create should have.
- Submit the partner questionnaire - Contact aws-iam-partner-onboarding@amazon.com or your AWS representative with your account IDs, Marketplace product ID, policy templates, and integration description.
- Iterate with AWS - Expect feedback on your policy templates. AWS takes least privilege seriously here.
- Integrate the APIs - Once approved, you'll receive ARNs for your policy templates and can call CreateDelegationRequest and GetDelegatedAccessToken from your registered accounts.
- Build the UX - Add a "Connect with AWS" button in your product that kicks off the delegation flow. The customer experience should feel native and seamless.
What we've learned advising ISVs
From our work helping ISVs shape their go-to-market strategies on AWS, here are a few practical considerations:
Start with your onboarding flow
Map out every step where a customer currently interacts with IAM or any other AWS resource creation. IAM Temporary Delegation can likely replace most of them.
Design for both personas
A developer on a personal account will approve immediately. An enterprise platform engineer will need to route it through their admin. Your UX should handle both gracefully.
Use it for feature adoption too
IAM Temporary Delegation isn't just for initial onboarding. When you ship a new feature that needs additional AWS permissions, you can trigger a new delegation request rather than sending customers back through manual configuration.
Instrument your funnel
Measure completion rates before and after. The data from launch partners suggests dramatic improvements in onboarding conversion - use that to justify the integration investment.
Least privilege is non-negotiable
AWS reviews your policy templates. Don't request *:* and hope for the best. Scope tightly to what you actually need. Customers can see exactly what you're asking for, and over-broad requests erode trust.
The bigger picture
IAM Temporary Delegation represents a shift in how AWS thinks about the partner ecosystem. Rather than leaving cross-account access as a customer-configured, documentation-driven exercise, AWS is building it into the platform as a first-class, consent-driven workflow.
For ISVs pursuing product-led growth, this removes one of the most significant barriers to self-serve adoption on AWS. The combination of frictionless onboarding, transparent permissions, built-in governance, and full auditability means you can serve individual developers and enterprise security teams with the same integration.