Overview

SecureSpect connects to your AWS account using a read-only cross-account IAM role. No secret access keys are ever created, stored, or transmitted. The connection uses AWS's native STS AssumeRole mechanism — the same pattern AWS recommends for all third-party integrations.

This guide walks you through every step from opening the AWS Console to seeing your first control scan results.

Prerequisites

• An active SecureSpect account and workspace
• AWS Console access with permissions to create IAM roles
• The IAM role creation permission (iam:CreateRole, iam:AttachRolePolicy)

Step 1 — Start the Connection in SecureSpect

Navigate to Integrations in the SecureSpect sidebar.

Find the AWS card and click Connect.

SecureSpect generates a unique External ID — copy it. You'll paste this into the AWS Console in Step 3. Do not close this dialog.

The External ID is a one-time, cryptographically random value that prevents confused deputy attacks. Never reuse it across connections.

Step 2 — Open the AWS Console

In a separate browser tab, sign in to your AWS Console and navigate to:

IAM → Roles → Create role

Choose AWS account as the trusted entity type, then select Another AWS account.

Enter the SecureSpect platform Account ID (shown in the dialog in Step 1).

Tick Require external ID and paste the External ID you copied from SecureSpect.

Step 3 — Attach the Permissions Policy

On the Add permissions screen, you have two options:

Option A (Recommended for quick setup): Attach the AWS-managed ReadOnlyAccess policy. This is the broadest safe option and covers all current and future SecureSpect checks.

Option B (Least-privilege custom policy): If your security team requires tighter scoping, attach a custom policy using only the specific actions SecureSpect needs. The full list is available in the app under Required permissions on the AWS integration card. This list includes actions across IAM, S3, EC2, RDS, CloudTrail, KMS, Secrets Manager, GuardDuty, Inspector, WAF, Lambda, VPC, ECS, EKS, and ElastiCache.

Step 4 — Name and Create the Role

Give the role a descriptive name, for example:

SecureSpectReadOnly

Review the trust policy (it should show your SecureSpect platform account and the External ID), then click Create role.

Open the newly created role and copy its ARN — it looks like:

arn:aws:iam::123456789012:role/SecureSpectReadOnly

Step 5 — Complete the Connection in SecureSpect

Return to the SecureSpect dialog, paste the Role ARN into the Role ARN field, and click Connect.

SecureSpect immediately runs a validation check by attempting to assume the role. If successful, the integration status changes to Connected and the first sync begins automatically.

Troubleshooting

"Could not assume role" error

• Verify the External ID in the trust policy exactly matches the one SecureSpect generated.
• Verify the trusted AWS account ID is correct (shown in the SecureSpect dialog).
• Confirm the role has a policy attached (a role with no policy has no permissions).

Partial sync failures Some evidence types may fail if you used Option B and are missing specific actions. Check the Integrations page for the list of failing evidence types and cross-reference against the Required Permissions list.

"Access denied" during scan The role was assumed successfully but specific actions are denied. Add the missing permissions to your custom policy using the Required Permissions list as reference.

Security Notes

• SecureSpect never stores AWS access keys. Authentication uses the IAM AssumeRole API only.
• The External ID is stored server-side and validated on every AssumeRole call, preventing confused deputy attacks.
• You can revoke SecureSpect's access at any time by deleting or modifying the IAM role trust policy.
• The cross-account role is read-only — SecureSpect cannot modify any resource in your AWS account.