How Should an AWS Managed Service Provider Get Into Your Account?

The first email from most managed AWS services providers asks for the same thing: an IAM user with AdministratorAccess, or the root email so they can "set things up properly". A surprising number of fintechs send it. Six months later the account has a vendor-named user with two access keys, no MFA, shared across the vendor's rota, and a CloudTrail that says msp-admin did everything.

That is the moment the engagement is decided, before the SLA is read. An AWS managed service provider that cannot be held to a named person in your audit trail cannot be held to anything, because the trail is all you have when the RBI or an auditor asks who changed the security group at 2am.

Our position: the access model is the contract. Get it right on day one, with a cross-account role you own, an external ID, a source identity that carries the engineer's name and no long-lived keys, and most of the questions in the contract answer themselves. Get it wrong and no clause fixes it.

Why does the access model matter more than the SLA?

Because the regulator asks about it directly and the SLA does not. The RBI NBFC Cybersecurity Directions 2026 want audit trails that serve "as forensic evidence when required" (paragraph 21(8)), privileged users "with all their system activities logged and periodically reviewed" (paragraph 114), and multi-factor authentication for them (paragraph 115). The 2025 outsourcing directions add that vendor staff access is limited to what the work needs (paragraph 24) and that cloud arrangements use role-based access (paragraph 97(viii)). The contract side is in the RBI outsourcing contract post; this is the engineering side of question five on that list.

A shared user fails all of those at once. The activity is logged, but against a login nobody can map to a person. MFA is off because five people share the password. And the "need to know" limit is AdministratorAccess on everything.

The badge does not settle it either. AWS's MSP Program validates a provider through a third-party audit of "technical skills and business health", not of how it is wired into your account. A validated MSP can still ask for an admin user, and some do.

What is wrong with giving the vendor an IAM user?

AWS's own guidance, for a start. The IAM security best practices open with "require human users to use federation with an identity provider to access AWS using temporary credentials", and reserve long-term access keys for tools "that don't support access with IAM Identity Center". A vendor's engineers are human users. Their laptops support federation.

Then the three things that go wrong. A key never expires on its own; it outlives the engineer, the contract renewal and, in the worst case we see, the vendor. Shared between two people, it makes the audit trail fiction. And offboarding means changing a password in a system you do not control, which nobody does.

Run the credential report and sort by access_key_1_last_rotated. If the oldest active key belongs to a vendor, and it usually does, that is the day this post is about: an admin credential nobody is watching, the same shape as the instance-role problem in the SSM Agent CVE post.

What should the AWS managed service provider's role look like?

A role in your account whose trust policy names the vendor's AWS account, requires an external ID and requires a source identity, the engineer's name as set by their identity provider. Their engineers sign into their own account through that provider, with MFA enforced there, then assume your role. You own the role, the permissions and the ability to delete it.

The external ID is not decoration. AWS's confused deputy page uses exactly this scenario, a third party hired "to monitor your AWS account and help optimize costs": a role ARN "isn't a secret", so another of its customers who guesses yours could have it act in your account. The ID must be "controlled by Example Corp, not its customers", which is why they issue it and you do not. A vendor that has never heard of it is telling you how many other accounts it has secured.

This is the trust policy we ask a client to create for us, with our account id and external ID filled in:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VendorAssumeRole",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::VENDOR_ACCOUNT_ID:root" },
      "Action": ["sts:AssumeRole", "sts:SetSourceIdentity"],
      "Condition": {
        "StringEquals": { "sts:ExternalId": "VENDOR_ISSUED_EXTERNAL_ID" },
        "Null":         { "sts:SourceIdentity": "false" }
      }
    }
  ]
}

Two conditions. The external ID stops the confused deputy. The Null check refuses any assume-role call that does not carry a source identity, so a session with no name attached never gets in. Scope the permissions policy to the engagement, cap the session at an hour, and keep the role under your service control policies.

Why not a session-name or MFA condition? Because neither survives federation. AWS's global condition keys page says aws:MultiFactorAuthPresent "is not present for federated identities", and aws:username, which the usual session-name pattern relies on, is absent for roles and Identity Center sessions. So MFA is enforced at the vendor's provider and written into the contract, and the name travels as source identity.

How do you know which of their engineers did what?

Because source identity cannot be changed once set. AWS's page on monitoring assumed roles says the value "persists when a role is used to assume another role" and "cannot be changed during the role session", and it lands in sessionContext.sourceIdentity on every CloudTrail event the session generates. A session name is chosen fresh at each hop by whoever is calling, so a script can name every session ops and the trail is no better than the shared user was.

So the vendor's identity provider passes the engineer's name as the source identity at sign-in, your trust policy requires it, and every action in your account carries that name through however many roles it passed. To allow-list the named essential personnel the outsourcing direction asks for, add a StringLike condition on sts:SourceIdentity, as in AWS's own role-chaining example.

The test: ask for a harmless change, then run:

aws cloudtrail lookup-events \
  --start-time "$(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --output json \
  | jq -r '.Events[] | .CloudTrailEvent | fromjson
      | select(.userIdentity.sessionContext.sessionIssuer.userName == "VendorRole")
      | [.eventTime, .eventName, .userIdentity.sessionContext.sourceIdentity] | @tsv'

If the third column is a person's name, the model works. If it is null, or the same value for three different engineers, it does not, and no SLA report will tell you who did what on the night it matters.

What about the vendor's pipelines and tools?

The same rule with a different identity provider. Deploy pipelines run in your repositories and assume a role in your account through OIDC, so the vendor leaving on Friday does not stop Monday's deploy; that is the test from the hire-or-partner comparison, and the GitHub Actions shape is in the checkout-change post. For anything outside AWS the best-practices page lists IAM Roles Anywhere and AssumeRoleWithWebIdentity; neither is an access key in a CI secret.

What can you run on Monday?

Two commands and one console click. The first lists every long-lived key in the account and how old it is:

aws iam generate-credential-report >/dev/null
aws iam get-credential-report --query Content --output text | base64 -d \
  | cut -d, -f1,8,9,10,11,12 | column -s, -t

That prints the user, whether MFA is on, and for the first access key whether it is active, when it was rotated, and when and from which region it was last used. Anything active, older than a year and used from a region you do not operate in is the finding. The root user is in the report too; check that row first.

The console click is an IAM Access Analyzer external access analyzer. It reads every resource-based policy in the account, role trust policies included, and raises a finding for each principal outside your organisation that can reach one: the inventory of who can get in, which the outsourcing direction assumes you already have. Create one in every region you use; external access findings are per region.

Then paste the trust policy above onto a new role, hand the ARN to the vendor, and delete the user.

When is the IAM user the honest answer?

Sometimes, and AWS says so. A tool that genuinely cannot federate is the case the best-practices page carves out, and a break-glass user with hardware MFA, kept in a vault you control, is reasonable for a two-person startup to hand a partner while the organisation and identity provider get built. The condition is that it is temporary, it is one named human, and the credential report is checked monthly until it is gone.

There is also a model where the MSP creates your accounts inside its own AWS organisation. With no platform team and nothing regulated in the account, that can be the right trade, because the guardrails arrive on day one. For a fintech it is not, because the exit the outsourcing direction requires becomes a migration, and the management account belongs to someone you might one day have to leave. Own the organisation. Let the vendor assume roles in it.

The short version

Run the credential report and find the vendor's keys. Create a role in your account with an external ID the vendor issued, a required source identity, MFA at the vendor's identity provider, and a permissions policy scoped to the engagement. Turn on an external access analyzer in every region. Make one change through the new role and confirm CloudTrail shows a person. Then delete the IAM user, and ask the vendor which of its other customers still have one.

If a managed AWS services provider will not work this way, that is the evaluation finished early. We do, and the trust policy above is the one we send.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.