Terraform verifies a provider by comparing the downloaded package to checksums it recorded earlier in the dependency lock file. This is a trust on first use model: the first install is your decision, and later installs of the same version must match what you accepted.
What gets checked
When terraform init installs a provider, it requires the package to match at least one checksum already in .terraform.lock.hcl. If none match, init stops with an error saying the package does not match the checksums previously recorded. That protects you from a changed package appearing under the same version number later.
If a provider's origin registry publishes signed checksums, Terraform treats all the signed checksums as valid as long as one matches. The lock file then holds checksums for your platform and for other platforms. The init output also shows the key ID that signed them.
What is left to you
The first-use step has no automatic judgement. HashiCorp describes it as a point where you can verify the provider in whatever way you choose or any way your regulations require. Nothing in Terraform decides that a provider is safe to run with your cloud credentials.
A provider is a program that runs on your machine or CI runner and talks to your cloud account, so the first-use review matters.
A short review routine
- Confirm the source address, for example the namespace and name, matches the publisher you expect.
- Read the key ID in the init message and decide whether you trust that holder.
- Check the publisher's repository and release history.
- Commit the lock file change in its own pull request so reviewers see it.
- Treat a lock file change you did not make as a finding to explain.
Why the lock file belongs in version control
HashiCorp recommends committing the lock file so that dependency changes can be discussed in code review, just like configuration changes. A diff that adds a provider block or changes a version is the moment to ask whether the change is intended.
Common misunderstandings
| Belief | What the documentation says |
|---|---|
| The lock file proves a provider is safe | It records what you accepted and detects change afterward |
| Signed checksums remove the need to review | You may still want to confirm you trust the key holder |
| Mirrors are checked the same way | A mirror install cannot see checksums for other platforms until you add them |
Quick check
Is a lock file mismatch always an attack?
No. It may come from a re-published package, a mirror problem, or a platform difference. It should still be investigated before you override it.
What does the -upgrade flag do?
It tells init to ignore existing selections and choose the newest version matching your constraints, which will change the lock file.
Does Terraform check the code inside a provider?
No. It checks that the package matches recorded checksums, not that the code is free of defects.
Safeguard offers SBOM and dependency scanning and policy gates that can block a pull request on findings, and you can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
