Connect your AWS account

Go to app.cloudcerta.com. You will be sent to the CloudCerta sign-in page, which supports Google or an email and password.

No invitation yet? Ask whoever set up your organisation to send one from Team → Invite.

The first time you sign in, CloudCerta asks for your organisation details. This names your tenant and appears on reports. You will only see it once; afterwards you land on the dashboard.

A target is something CloudCerta assesses. For Cloud Posture, that is one AWS account.

Open Targets and add one. Give it a name you will recognise — Production beats an account number, because the name is what appears on the dashboard and in reports.

The target starts disconnected. Nothing has touched AWS yet.

Open the target, start the connect wizard, and on Step 1 — Connect AWS click Generate connection details. CloudCerta produces four things:

• External ID — a unique secret tying this role to your tenant. Treat it as sensitive.
• CloudGuard account ID — the AWS account that will assume your role.
• Trust policy (JSON) — who may assume the role, and under what condition.
• Managed policy to attach — the permissions the role gets. SecurityAudit, nothing else.

Nothing in your AWS account changes at this point. These are instructions for you to apply, not actions CloudCerta takes.

Note the expiry shown under the instructions. If you do not finish in time, click Regenerate connection details and use the new values — the old External ID stops working.

The only part that happens in the AWS Console. This section is self-contained if you need to hand it to someone else.

1. AWS Console → IAM → Roles → Create role.
2. For Trusted entity type choose Custom trust policy, and paste the trust policy from step 4. It already names the CloudCerta principal and requires your External ID, so you do not enter those separately.
3. On Add permissions, attach the AWS-managed policy SecurityAudit. Do not add any other policy — CloudCerta does not need more and will not use more.
4. Name it, for example CloudGuardReadOnly, and create it.
5. Open the role and set Maximum session duration to one hour or less.
6. Copy the role ARN.

Two things are worth checking in the trust policy before you save, because they are what make this safe: the Principal is a single ARN — never *, never an account root — and the sts:ExternalId condition is present.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "<CloudCerta principal, shown in the wizard>" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "<your unique External ID>" }
      }
    }
  ]
}

Back in CloudCerta, go to Step 2 — Validate connection, paste the role ARN, and click Validate connection.

CloudCerta assumes the role once and checks it can read what it needs. On success the target shows Verified. If it fails, the message is specific — see troubleshooting.

From the dashboard or the target page, click Run scan. A first scan on a populated account takes a few minutes, and the button shows live progress. When it finishes you get a score, a grade, and findings grouped by severity.

About your first score. Anything CloudCerta could not read is reported as not assessed— never as passing. If a service was unreachable or outside SecurityAudit’s reach, you will see it called out rather than quietly counted as compliant. A lower score with honest gaps is the intended behaviour.