DSPM troubleshooting

Organised by what you actually see, because most of these look like a different problem than they are.

The scanner will not start

What you see	Cause	Fix
`enrollment token not recognised`	Wrong or revoked token.	Mint a new one in Scan Configuration and update the secret the task reads.
`exec format error`	Image architecture mismatch.	Pull the multi-arch tag, not a single-arch digest. Both `linux/amd64` and `linux/arm64` are published.
`DSPM_ORG_ID is required`	The task cannot identify its tenant.	Set it from the console’s account page.
`verification is refused in the connected deployment`	Credential verification is only for in-account.	Set `DSPM_VERIFY_CREDENTIALS=false`, or run the in-account scanner.

Check the token without deploying anything:

curl -s https://api.tigergate.dev/api/dspm/enrollment/status \
  -H "Authorization: Bearer <token>"

{ "organization_id": "…", "account_id": null, "allowed": true, "code": "ok" }

allowed: false is an entitlement block, not a bad token — code says which. This is worth running before every deploy: it is the difference between failing in a second and failing after you have paid for a task.

The scan ran but nothing appeared

Work down this list in order.

Did the report leave?

aws logs tail /tigergate/dspm --follow

The first two lines are the whole test:

[inaccount] enrollment valid: org=… account=…
[inaccount] reporting to https://api.tigergate.dev/api/dspm/reports

Read the second one. A stack pointed at the wrong environment shows up here rather than after the findings land somewhere unexpected.

Did it arrive?

Scan Configuration shows merged / in flight / parked / last merged.

in flight — staged; the merge worker folds it in within about a minute.
parked — failed three times and will not retry. This one needs a person.
last merged: never — nothing has ever landed. Go back to the logs.

Is the network right?

The scanner needs outbound HTTPS to ReportEndpoint and nothing else. If your subnets have no NAT and no endpoint, the task runs, scans, and cannot ship. That looks identical to “found nothing” from the console.

Coverage states, and what each one costs you

Only ok with no classifications means “we looked and found nothing”. Everything else means we did not finish looking.

State	Means	Fix
`ok`	Read and classified.	—
`never`	Not yet read. Not clean.	No content scan has been requested for this store.
`denied`	The credential was refused.	Missing grant — add `s3:GetObject`, and `kms:Decrypt` for SSE-KMS.
`unreachable`	No network path.	Commonly a private database. Needs the connector or a VPC route.
`unsupported_format`	Opened, could not be parsed.	No connector reads this store type yet.
`budget_exhausted`	Stopped at the profile’s cap.	Raise the profile, or accept partial coverage across runs.

A store in any state but ok is not a store with no sensitive data. Zero findings across forty unreadable stores is a coverage gap, not a clean estate — which is why every count in the console carries its denominator.

After fixing a permission, a denied store waits out a seven-day cool-off before retrying, because the fix is a human action on your side and retrying every fifteen minutes would burn API calls for a week. To retry immediately, use Rescan on the store.

Everything reports `denied`

The credential is fine and the grant is not. Prove which:

aws sts get-caller-identity     # is the identity what you think it is?

Then check the content scope. An empty ContentScanBuckets (AWS), contentScanAccounts (Azure) or contentScanScope (GCP) means the role was deliberately not granted object read — that is inventory-and-posture mode working as designed, not a fault. Name the buckets to turn content classification on.

`0 stores discovered`

Either the role has no read permission, or ScanRegions names regions you use nothing in. Regions you do not use cost nothing but produce exactly this.

The console says the account has “gone quiet”

The Expected reporting interval does not match how you actually run the scanner. TigerGate cannot start your scanner, so this setting is the only thing that lets the console tell a scanner that stopped from an estate that has not changed.

Running on a schedule → set it to the same cadence.
Running by hand, or with run_mode = "once" → set it to On demand.

An account set to On demand is listed under Not monitored rather than shown as healthy. That is the honest trade: nothing is watching it, and the console says so instead of implying all is well.

A record count is blank

Two causes, neither an error:

No content scan has run for that store yet.
The sample was under 50 records — the estimator refuses to extrapolate where the interval would swamp the estimate.

A 0 would be a claim that the store holds none, and a sample of twelve does not support that. The data types found are still shown; only the count is withheld. A count with a + beside it means some types were projected and others were not — the total is a floor, not a whole.

A store shows no accessors

The IAM graph has not been built for that account, so reachability is unknown rather than absent. The console says which, and never renders an unbuilt graph as “nothing can reach this”.

The scan is slower or more expensive than expected

Almost always the list API on a store with hundreds of millions of objects. Every run lists every object — that is how new and deleted ones are seen — and at roughly $5 per million requests that adds up long before the reading does. The scanner caps itself at DSPM_LIST_API_MAX_OBJECTS (default 1,000,000) and raises DS-COV-006 when S3 Inventory should be configured instead. Configure it; the scanner will use it and stop paying to list.

Credential verification finds nothing

Verification is off by default. When on, it is refused unless the deployment is in-account, and the binary must be built with it:

credential verification was requested but this binary was built without it;
rebuild with -tags trufflehog, or set DSPM_VERIFY_CREDENTIALS=false

An unknown verdict is not unverified. It means we could not tell — no egress, a rate limit, an outage — and it stays distinct so a live key is never downgraded during the outage that stopped us checking it.

Getting the logs

AWS
Azure
GCP

aws logs tail /tigergate/dspm --follow

az containerapp job logs show \
  --name tigergate-dspm --resource-group tigergate-dspm --follow

gcloud logging read \
  'resource.type=cloud_run_job AND resource.labels.job_name=tigergate-dspm' \
  --limit 100

​The scanner will not start

​The scan ran but nothing appeared

​Coverage states, and what each one costs you

​Everything reports denied

​0 stores discovered

​The console says the account has “gone quiet”

​A record count is blank

​A store shows no accessors

​The scan is slower or more expensive than expected

​Credential verification finds nothing

​Getting the logs

The scanner will not start

The scan ran but nothing appeared

Coverage states, and what each one costs you

Everything reports `denied`

`0 stores discovered`

The console says the account has “gone quiet”

A record count is blank

A store shows no accessors

The scan is slower or more expensive than expected

Credential verification finds nothing

Getting the logs