State refreshes on non existent resources return 403, not 404

[mardonner]

Description

Hi, I recently noticed that my pipelines are failing in a way they didn't before.
At the start of the day, I create a sandbox of my infrastructure with instances of ske, secrets manager, s3 and so on. At the end of the day, I start my destruction pipeline and log off.
Usually, this pipeline fails, because ske destruction takes too long. This is fine, since the "expensive stuff" is already deleted.
The next day, I start the destruction again to delete the remaining resources before creating another sandbox.

Now, since this week, I'm seeing failing pipelines on the second destruction run.
The first destruction run deleted my ske cluster and my secrets manager. The s3 and dns are still there. Since, the pipeline crashed, the deletion of ske were not commited to the state file.

When running the second destroy now, I get 403 errors on the ske and sm resources during state refresh. Previously, tofu was smart enough to recognize that the infra changed and just removes them from the sate file.

This is what it looks like:

# during tofu plan
module.cluster.stackit_secretsmanager_instance.sm_cluster: Refreshing state... [id=xyz,xyz]
╷
│ Error: Error reading instance
│ 
│   with module.cluster.stackit_secretsmanager_instance.sm_cluster,
│   on .terraform/modules/cluster/secrets_manager.tf line 10, in resource "stackit_secretsmanager_instance" "sm_cluster":
│   10: resource "stackit_secretsmanager_instance" "sm_cluster" {
│ 
│ Calling API: 403 Forbidden, status code 403, Body: {"message":"Forbidden"}
│ 
│ 
│ Trace ID: "fb93a1235d5f3dad46267391dda5147a"
╵

TF_LOG=TRACE did not show any useful information. Is there a way to run the provider / sdk in debug mode?

I'm confused why I'm getting a 403 instead of a 404 on the missing resource. There were no changes regarding permissions for my service account.

Steps to reproduce

1. Create a resource with terraform
2. Delete it in portal (to simulate my failing pipeline, by changing the resource outside of tf)
3. Run terraform destroy
4. get 403 instead of 404

Environment

• OpenTofu v1.11.5
• Version of the STACKIT Terraform provider: v0.112.0
• stackit cli v0.71.0

Additional Information

The stacckit cli returns the same error.

stackit --version
STACKIT CLI
Version: 0.71.0 (2026-08-12)

stackit secrets-manager instance describe <myID> --verbosity debug
Aug 18 10:02:20.728 DBG arguments: [secrets-manager, instance, describe, <smID>, --verbosity, debug]
Aug 18 10:02:20.728 DBG configuration is persisted and read from: /home/marceldonner/.config/stackit/cli-config.json
Aug 18 10:02:20.728 DBG read configuration profile "default" via 
Aug 18 10:02:20.728 DBG active configuration profile: default
Aug 18 10:02:20.728 DBG configuration keys: [allowed_url_domain: stackit.cloud, assume_yes: false, async: false, project_id: <projectID>, region: eu01, session_time_limit: 12h, verbosity: debug]
Aug 18 10:02:20.728 DBG parsed input values: [AssumeYes: false, Async: false, InstanceId: <smID>, ProjectId: <projectID>, Region: eu01, Verbosity: debug]
Aug 18 10:02:20.731 DBG authenticating using user token
Aug 18 10:02:20.731 DBG request to https://secrets-manager.api.eu01.stackit.cloud/v1/projects/<projectID>/instances/<smID>: GET HTTP/1.1
Aug 18 10:02:20.731 DBG request headers: [Accept: application/json, User-Agent: stackit-cli/0.71.0]
Aug 18 10:02:20.896 DBG response from https://secrets-manager.api.eu01.stackit.cloud/v1/projects/<projectID>/instances/<smID>: HTTP/2.0 403 Forbidden
Aug 18 10:02:20.897 DBG response headers: [Content-Type: application/json, Date: Tue, 18 Aug 2026 08:02:20 GMT, Referrer-Policy: strict-origin]
Aug 18 10:02:20.897 DBG response body: [message: Forbidden]
Aug 18 10:02:20.897 ERR execute command: read Secrets Manager instance: 403 Forbidden, status code 403, Body: {"message":"Forbidden"}


Error: read Secrets Manager instance: 403 Forbidden, status code 403, Body: {"message":"Forbidden"}
# ...

Was there a change on the API or is this some auth issue?

[Fyusel]

Hi @mardonner,
thank you for reporting this issue.

Can you please provide a simple (full) terraform config. This will help us to try to reproduce this behavior.

[mardonner]

Will later but you can also reproduce it with stackit cli. Create a sm, get id, delete it, try to query a sm with the id.