AWS member accounts discovery fails with Status Code: 401 Issue The management account corresponds to the Organization in AWS. You can identify any cloud service account in your instance as a management account only if you already configured the account in AWS as an Organization and you already associated other accounts under the Organization. Requirement: Amazon Technical Account confirmed the Service account should use a management account for Discovery and then use STS with specific roles for each member. Doc: Managing the AWS Accounts in Your Organization Minimum Permissions: To access an AWS account from any other account in your organization, you must have the following permission: sts: AssumeRole – The Resource element must be set to either an asterisk (*) or the account ID number of the account with the user who needs to access the new member account" Discovery of AWS member accounts using the credentials of the parent account may fail with the error: "AWS was not able to validate the provided access credentials (Service: AmazonEC2; Status Code: 401; Error Code: AuthFailure; Request ID: xxxxxx-xxxx-xxxxx" The credentials for the parent account of the AWS organization work successfully and can discover the parent account. However, obtaining a temporary token via Amazon STS for a member account using the parent account credentials will be not working.ReleaseAll releases. Instance activated with CMPv2 plugin and configured with AWS Management Service Account. CauseWhen discovering member accounts, the AWS Discovery credential and management service accounts are used to generate a temporary token. In order to generate this token, the management account needs to have the "AssumeRole" permission.ResolutionEnsure the "OrganizationAccountAccessRole" is available and that has the "AssumeRole" permission.Related LinksCan Discovery/MID Server be configured to use another role other than OrganizationAccountAccessRole? No, unfortunately, the STS override workaround is not going to be feasible. Additionally, and also for security, SN does not offer any methods available to use from the MID server level for decrypting passwords. MID servers store passwords in memory for this reason, so we cannot manually retrieve and decrypt credentials to make this function call, which would also be a security concern. A workaround would be to customize the default OrganizationAccountAccessRole to your desired role, and then create a new custom role with the admin rights that you would want your users to use as your "administrative link".