Many teams no longer build servers, networks and cloud accounts by hand. They describe them in text files, and a tool such as Terraform builds them. To know what it built, the tool keeps one file: the state. That file is a complete map of your infrastructure, it often holds passwords, and without it the tool no longer knows what it owns. Five things decide whether it is an asset or a liability. Veel teams bouwen servers, netwerken en cloudaccounts niet meer met de hand. Ze beschrijven ze in tekstbestanden, en een tool als Terraform bouwt ze. Om te weten wat hij bouwde, houdt de tool één bestand bij: de state. Dat bestand is een volledige kaart van uw infrastructuur, bevat vaak wachtwoorden, en zonder dat bestand weet de tool niet meer wat van hem is. Vijf dingen bepalen of het een bezit is of een risico.
With IaC, the code says what you want: three servers, one database, a network. When Terraform builds them, the cloud gives each one an ID. Terraform writes those IDs down in the state, by default a text file called terraform.tfstate. Next time, it compares code, state and reality, shows the difference as a plan, and changes only that.
Business impact: the state is how the tool knows what it is responsible for. Lose it, and Terraform sees an empty world: it may try to build everything a second time, or no longer tidy up what exists. A wrong or outdated state can make it change or delete the wrong thing. It is also a complete, current inventory of your estate, which is useful to you and to an attacker.
Bij IaC zegt de code wat u wilt: drie servers, één database, een netwerk. Als Terraform ze bouwt, geeft de cloud elk een ID. Terraform schrijft die ID's op in de state, standaard een tekstbestand met de naam terraform.tfstate. De volgende keer vergelijkt het code, state en werkelijkheid, toont het verschil als een plan, en verandert alleen dat.
Bedrijfsimpact: via de state weet de tool waarvoor hij verantwoordelijk is. Raakt u die kwijt, dan ziet Terraform een lege wereld: het kan alles een tweede keer proberen te bouwen, of niet meer opruimen wat er staat. Een verkeerde of verouderde state kan het verkeerde ding laten wijzigen of verwijderen. Het is ook een volledige, actuele inventaris van uw omgeving, nuttig voor u en voor een aanvaller.
A stolen state file is a map of your estate. AI tools turn it into a list of targets and weak spots in minutes.Een gestolen statebestand is een kaart van uw omgeving. AI-tools maken er in minuten een lijst van doelwitten en zwakke plekken van.
An AI agent allowed to run Terraform can delete whatever the state says it owns, as fast as a person and without hesitating.Een AI-agent die Terraform mag draaien, kan verwijderen wat volgens de state van hem is, net zo snel als een mens en zonder aarzelen.
AI can read a long plan and flag unexpected deletions before anyone approves it. A person still approves.AI kan een lang plan lezen en onverwachte verwijderingen aanwijzen voordat iemand het goedkeurt. Een mens keurt nog steeds goed.
HashiCorp's documentation is clear: if a secret is in the configuration, Terraform stores it in the state and the plan. The state itself is a plain text file. Cloud storage encrypts it at rest by default, but AWS and Microsoft both decrypt it automatically for anyone allowed to read it. Encryption at rest protects against a stolen disk, not against a colleague, a pipeline or an attacker who holds read rights.
Business impact: everyone who can read the state can read the database passwords and keys inside it. That list is usually longer than anyone thinks: platform engineers, the pipeline, its runners, and in GitLab by default every Developer on the project. Newer Terraform and provider features can keep a secret out of the state altogether, where the provider supports them. A key held in a separate key service, such as KMS, adds a second gate: no key permission, no readable file.
De documentatie van HashiCorp is duidelijk: staat een geheim in de configuratie, dan slaat Terraform het op in de state en in het plan. De state zelf is een gewoon tekstbestand. Cloudopslag versleutelt het standaard, maar AWS en Microsoft ontsleutelen het allebei automatisch voor iedereen die het mag lezen. Versleuteling in opslag beschermt tegen een gestolen schijf, niet tegen een collega, een pipeline of een aanvaller met leesrechten.
Bedrijfsimpact: iedereen die de state kan lezen, kan de databasewachtwoorden en sleutels erin lezen. Die lijst is meestal langer dan iemand denkt: platformengineers, de pipeline, de runners ervan, en in GitLab standaard elke Developer op het project. Nieuwere functies van Terraform en providers kunnen een geheim helemaal buiten de state houden, waar de provider dat ondersteunt. Een sleutel in een aparte sleuteldienst, zoals KMS, voegt een tweede slot toe: geen sleutelrecht, geen leesbaar bestand.
An attacker who finds one state file can have AI pick out every password, key and connection string in seconds.Een aanvaller die één statebestand vindt, laat AI er in seconden elk wachtwoord, elke sleutel en alle verbindingsgegevens uithalen.
An engineer pastes a state file or plan into a public AI chat to debug an error, and the secrets inside leave with it.Een engineer plakt een statebestand of plan in een publieke AI-chat om een fout op te lossen, en de geheimen erin gaan mee.
Secret scanners, increasingly AI-assisted, can check state files and repositories for live credentials before an attacker does.Geheimenscanners, steeds vaker met AI, kunnen statebestanden en repositories op werkende inloggegevens controleren voordat een aanvaller dat doet.
If two people or pipelines change the same infrastructure at once, both write the state, and one overwrites the other. Locking stops that: the first one in holds the lock, the second waits. Some storage gives you locking automatically. With Amazon S3 it is switched off unless you turn it on. Versioning keeps every earlier copy of the state, so a bad write can be undone. HashiCorp highly recommends it for S3.
Business impact: a corrupted or overwritten state can lead Terraform to rebuild or remove production systems, and the repair is slow, manual work by your most senior engineers. Terraform has a command to break a stuck lock, with a warning in its own documentation to be very careful with it. Worth asking: is locking on, is versioning on, and has anyone ever restored an old state version?
Als twee mensen of pipelines tegelijk dezelfde infrastructuur wijzigen, schrijven ze allebei de state, en overschrijft de een de ander. Vergrendelen voorkomt dat: wie het eerst komt, houdt het slot, de tweede wacht. Sommige opslag geeft u dat slot automatisch. Bij Amazon S3 staat het uit tot u het aanzet. Versiebeheer bewaart elke eerdere kopie van de state, zodat een foute schrijfactie terug te draaien is. HashiCorp raadt dat voor S3 sterk aan.
Bedrijfsimpact: een beschadigde of overschreven state kan Terraform productiesystemen laten herbouwen of verwijderen, en het herstel is traag handwerk door uw meest ervaren engineers. Terraform heeft een commando om een vastgelopen slot te breken, met in de eigen documentatie de waarschuwing daar heel voorzichtig mee te zijn. Het loont om te vragen: staat vergrendeling aan, staat versiebeheer aan, en heeft iemand ooit een oude stateversie teruggezet?
Locking is a safety catch against accidents more than attackers. AI changes little for an outsider here.Vergrendeling is een veiligheidspal tegen ongelukken, meer dan tegen aanvallers. Voor een buitenstaander verandert AI hier weinig.
An AI agent that hits a stuck lock may "fix" it by forcing the lock open, the one step the documentation warns against.Een AI-agent die op een vastgelopen slot stuit, kan het "oplossen" door het slot te forceren, precies de stap waar de documentatie voor waarschuwt.
AI can summarise where code, state and the real estate disagree, so a team fixes drift before it causes a bad apply.AI kan samenvatten waar code, state en de echte omgeving verschillen, zodat een team afwijkingen herstelt voordat ze een foute apply veroorzaken.
Terraform stores state in a backend: a storage location such as an S3 bucket or an Azure storage account. That storage has to exist before Terraform can use it. But teams want everything built by Terraform, including that storage. So what builds the bucket that holds the state of the thing that builds the bucket? The backend settings cannot even use variables, so they are fixed before anything runs.
Business impact: the bottom layer is often built once, by one person, and then forgotten. It holds the state for everything above it, so whoever can delete or change it can make the whole estate unmanageable. There are three common answers. Build it with a small separate Terraform setup and then move its state in, which Terraform supports with terraform init -migrate-state. Build it by hand or with the cloud's own tooling, and document it. Or use a hosted service that provides the storage, so only an account and access tokens remain to protect. Your call; we suggest choosing one on purpose and writing down who owns it.
Terraform bewaart state in een backend: een opslagplek zoals een S3-bucket of een Azure-opslagaccount. Die opslag moet bestaan voordat Terraform hem kan gebruiken. Maar teams willen alles door Terraform laten bouwen, ook die opslag. Wat bouwt dan de bucket die de state bewaart van het ding dat de bucket bouwt? De backendinstellingen kunnen zelfs geen variabelen gebruiken, dus ze liggen vast voordat er iets draait.
Bedrijfsimpact: de onderste laag wordt vaak één keer gebouwd, door één persoon, en dan vergeten. Hij bewaart de state van alles erboven, dus wie hem kan verwijderen of wijzigen, kan de hele omgeving onbeheersbaar maken. Er zijn drie gangbare antwoorden. Bouw hem met een kleine aparte Terraform-opzet en verhuis daarna de state erin, wat Terraform ondersteunt met terraform init -migrate-state. Bouw hem met de hand of met de eigen tooling van de cloud, en leg het vast. Of gebruik een gehoste dienst die de opslag levert, zodat alleen een account en toegangstokens overblijven om te beschermen. Aan u de keuze; wij raden aan er bewust één te kiezen en op te schrijven wie de eigenaar is.
The account that built the bottom layer often keeps broad rights. AI-assisted attackers search for exactly such forgotten, powerful accounts.Het account dat de onderste laag bouwde, houdt vaak ruime rechten. Aanvallers met AI zoeken juist naar zulke vergeten, machtige accounts.
AI assistants write a working backend in seconds, but working is not safe: locking and versioning are easy to leave out.AI-assistenten schrijven in seconden een werkende backend, maar werkend is niet veilig: vergrendeling en versiebeheer zijn makkelijk vergeten.
Automated policy checks, with AI help, can confirm on every change that the state storage stays locked, versioned and private.Geautomatiseerde beleidscontroles, met hulp van AI, kunnen bij elke wijziging bevestigen dat de stateopslag vergrendeld, met versies en privé blijft.
| Where | What to know |
|---|---|
| HCP Terraform | HashiCorp's hosted service, called Terraform Cloud until April 2024. It stores and encrypts state for you. You trade a bucket to guard for an account and tokens to guard. |
| GitLab-managed state | State stored with the project, encrypted at rest, with versions and locking. By default anyone with the Developer role can download it; writing needs Maintainer. |
| Amazon S3 bucket | Encrypted by default since January 2023, but transparently. Locking is off until turned on, and HashiCorp highly recommends versioning. A customer-managed key in KMS lets you limit who can decrypt. |
| Azure storage account | Always encrypted, and that cannot be switched off, but again transparent to readers. Locking is built in. HashiCorp recommends signing in with Entra ID; storage access keys are not recommended for new setups. |
| GitHub, JFrog Artifactory | Terraform has no built-in GitHub backend. State kept in a GitHub repository is state in Git, which the controls below advise against. Artifactory can hold state in a Terraform Backend repository, with locking and history. Ask who can read that repository. |
| OpenTofu state encryption | OpenTofu can encrypt the state file itself, with a key from a key service, so a copied file is unreadable. It still cannot hide secrets from whoever runs it. |
| Waar | Wat u moet weten |
|---|---|
| HCP Terraform | De gehoste dienst van HashiCorp, tot april 2024 Terraform Cloud genoemd. Hij bewaart en versleutelt de state voor u. U ruilt een bucket om te bewaken in voor een account en tokens om te bewaken. |
| State in GitLab | State bewaard bij het project, versleuteld in opslag, met versies en vergrendeling. Standaard kan iedereen met de rol Developer hem downloaden; schrijven vraagt Maintainer. |
| Amazon S3-bucket | Sinds januari 2023 standaard versleuteld, maar transparant. Vergrendeling staat uit tot u die aanzet, en HashiCorp raadt versiebeheer sterk aan. Een eigen sleutel in KMS laat u beperken wie kan ontsleutelen. |
| Azure-opslagaccount | Altijd versleuteld, en dat kan niet uit, maar ook hier transparant voor lezers. Vergrendeling is ingebouwd. HashiCorp raadt aanmelden met Entra ID aan; toegangssleutels van de opslag worden voor nieuwe opzetten afgeraden. |
| GitHub, JFrog Artifactory | Terraform heeft geen ingebouwde backend voor GitHub. State in een GitHub-repository is state in Git, en dat raden de maatregelen hieronder af. Artifactory kan state bewaren in een Terraform Backend-repository, met vergrendeling en geschiedenis. Vraag wie die repository kan lezen. |
| Versleuteling in OpenTofu | OpenTofu kan het statebestand zelf versleutelen, met een sleutel uit een sleuteldienst, zodat een gekopieerd bestand onleesbaar is. Geheimen verbergen voor wie het draait, kan het nog steeds niet. |
Tokens for HCP Terraform or GitLab leak in logs and code. AI tools scan public code for them at scale.Tokens voor HCP Terraform of GitLab lekken in logs en code. AI-tools zoeken daar op grote schaal naar in openbare code.
AI agents are often handed one broad token for convenience. That token can then read every state, and every secret in it.AI-agents krijgen voor het gemak vaak één ruim token. Dat token kan dan elke state lezen, en elk geheim erin.
AI can help list who and what can read each state store, and flag access nobody has used in months.AI kan helpen opsommen wie en wat elke stateopslag kan lezen, en toegang aanwijzen die al maanden niemand gebruikt.
| Control | Addresses | In one line |
|---|---|---|
| Remote state, never in Git | The map (01) | State lives in one managed backend, not on laptops and not in a code repository, where HashiCorp warns it can expose secrets. |
| Changes only through the pipeline | The map (01) | People propose changes; the pipeline plans, a second person approves, the pipeline applies. Nobody applies to production from a laptop. |
| Secrets out of state | Secrets (02) | Retrieving a secret from a vault during a Terraform run does not prevent Terraform from storing it in state: ordinary data sources persist fetched values. Prevent storage by fetching secrets outside Terraform, at application runtime, or use ephemeral values and write-only arguments where the provider supports them. |
| Short, reviewed reader list | Secrets (02) | Read access to state is treated like access to the secrets in it, and reviewed every quarter. A customer-managed key adds a second gate. |
| Locking and versioning on | Locking (03) | Every backend locks during a change and keeps earlier versions. A restore of an old version is tested at least once a year. |
| A documented bootstrap | Chicken & egg (04) | The storage that holds state is built one known way, has a named owner, is protected against deletion, and its builder account keeps no standing rights. |
| Tokens with narrow scope | Where it lives (05) | Pipelines and AI agents get a token per workspace or project, not one for the whole organisation. |
| Maatregel | Pakt aan | In één zin |
|---|---|---|
| State op afstand, nooit in Git | De kaart (01) | State staat in één beheerde backend, niet op laptops en niet in een coderepository, waar HashiCorp waarschuwt dat geheimen kunnen uitlekken. |
| Wijzigen alleen via de pipeline | De kaart (01) | Mensen stellen wijzigingen voor; de pipeline maakt het plan, een tweede persoon keurt goed, de pipeline voert uit. Niemand past productie aan vanaf een laptop. |
| Geheimen buiten de state | Geheimen (02) | Het ophalen van een geheim uit een kluis tijdens een Terraform-run voorkomt niet dat Terraform het in de state opslaat: gewone data sources bewaren opgehaalde waarden. Voorkom opslag door geheimen buiten Terraform op te halen, op het moment van applicatie-runtime, of gebruik ephemeral values en write-only arguments waar de provider dat ondersteunt. |
| Korte, getoetste lijst lezers | Geheimen (02) | Leesrecht op state geldt als toegang tot de geheimen erin, en wordt elk kwartaal getoetst. Een eigen sleutel voegt een tweede slot toe. |
| Vergrendeling en versiebeheer aan | Vergrendelen (03) | Elke backend vergrendelt tijdens een wijziging en bewaart eerdere versies. Het terugzetten van een oude versie wordt minstens eens per jaar getest. |
| Een vastgelegde bootstrap | Kip & ei (04) | De opslag voor de state wordt op één bekende manier gebouwd, heeft een benoemde eigenaar, is beschermd tegen verwijderen, en het bouwaccount houdt geen vaste rechten. |
| Tokens met een smalle reikwijdte | Waar het staat (05) | Pipelines en AI-agents krijgen een token per workspace of project, niet één voor de hele organisatie. |
Secrets end up in state unless a team takes steps to keep them out, and read access tends to grow as teams and pipelines are added.Geheimen komen in de state terecht tenzij een team stappen zet om ze erbuiten te houden, en leesrechten groeien mee met elk nieuw team en elke nieuwe pipeline.
A leaked state hands over a map and the keys together. A lost or corrupted state can stall every infrastructure change until it is rebuilt by hand.Een gelekte state geeft een kaart en de sleutels tegelijk weg. Een verloren of beschadigde state kan elke infrastructuurwijziging stilleggen tot hij met de hand is herbouwd.
With secrets kept out, a short reader list, locking, versions and an owned bootstrap, a leak exposes a map without keys, and a bad write can be undone.Met geheimen erbuiten, een korte lijst lezers, vergrendeling, versies en een bootstrap met eigenaar onthult een lek een kaart zonder sleutels, en is een foute schrijfactie terug te draaien.
The platform or cloud lead owns the state stores and the bootstrap. The CISO reviews who can read them.De platform- of cloudlead is eigenaar van de stateopslag en de bootstrap. De CISO toetst wie ze kan lezen.
People and machine accounts that can read production state · state stores without locking or versioning · live secrets found in state by the last scan · months since the last restore test.Mensen en machineaccounts die productiestate kunnen lezen · stateopslagen zonder vergrendeling of versiebeheer · werkende geheimen in state bij de laatste scan · maanden sinds de laatste hersteltest.
“Infrastructure state files are readable by too many people or systems, contain live secrets, or cannot be restored, so that a leak exposes our estate and its credentials, or a lost state halts or damages production, which can lead to a breach and a notifiable incident.”“Statebestanden van onze infrastructuur zijn leesbaar voor te veel mensen of systemen, bevatten werkende geheimen, of zijn niet te herstellen, zodat een lek onze omgeving en inloggegevens blootlegt, of een verloren state productie stillegt of beschadigt, wat kan leiden tot een inbraak en een meldplichtig incident.”
| Framework | What it requires of you | When a supplier hands you their report | When this incident happens |
|---|---|---|---|
| NIS2 | NIS2 Art. 21(2) requires measures including backup (c), security in development and maintenance (e), cryptography (h), and access control and asset management (i). Well-run state can support all four. The Cyberbeveiligingswet has been in force since 15 August 2026. | If a supplier runs Terraform for you, ask where your state is kept, who on their side can read it, whether secrets are in it, and how they would restore it. | A leaked state with live credentials can count as a significant incident if it meets the thresholds. Early warning within 24 hours of becoming aware, incident notification within 72 hours, final report within one month. |
| DORA | Art. 8(4) requires mapping the configuration of ICT assets and their links; state can feed that map. Art. 9(4) requires access limited to what is needed. It also requires changes that are recorded, tested and approved. Art. 12 requires backups and tested restores. DORA has applied since 17 January 2025. | For ICT providers behind critical functions, ask for their state access list and restore evidence, and agree a right to see them in the contract. | Classify promptly. Initial notification within 4 hours of classifying it as major (at most 24 hours after becoming aware), intermediate report within 72 hours of the initial notification, final report within one month. |
| SOC 2 | Criterion CC6.1 covers logical access, which includes who can read state. CC8.1 covers change management, which includes how infrastructure changes are approved and applied. | Check whether the infrastructure pipeline and its state storage are in the system description. If they are not, the report says nothing about them. | A leak through over-broad state access will likely appear as an exception in the next report. |
| ISAE 3402 | The focus is financial reporting. State appears only through general IT controls on access and change, where the infrastructure supports the financial process. | The report rarely mentions infrastructure as code. Ask in the contract how changes to the platform under your service are controlled. | ISAE 3402 creates no duty to notify user auditors. Expect a deviation in the next report, and ask for interim disclosure in the contract. |
| Kader | Wat het van u vraagt | Als een leverancier u zijn rapport geeft | Als dit incident u treft |
|---|---|---|---|
| NIS2 | NIS2 art. 21 lid 2 vereist maatregelen waaronder back-ups (c), beveiliging bij ontwikkeling en onderhoud (e), cryptografie (h), en toegangsbeleid en beheer van bedrijfsmiddelen (i). Goed beheerde state kan alle vier ondersteunen. De Cyberbeveiligingswet is van kracht sinds 15 augustus 2026. | Draait een leverancier Terraform voor u, vraag dan waar uw state staat, wie aan hun kant hem kan lezen, of er geheimen in staan, en hoe ze hem zouden herstellen. | Een gelekte state met werkende inloggegevens kan als significant incident gelden als het de drempels haalt. Vroegtijdige waarschuwing binnen 24 uur na ontdekking, incidentmelding binnen 72 uur, eindverslag binnen een maand. |
| DORA | Art. 8 lid 4 vereist het in kaart brengen van de configuratie van ICT-middelen en hun verbanden; state kan die kaart voeden. Art. 9 lid 4 vereist toegang die beperkt is tot wat nodig is. Ook vereist het wijzigingen die worden vastgelegd, getest en goedgekeurd. Art. 12 vereist back-ups en periodiek geteste herstelprocedures. DORA geldt sinds 17 januari 2025. | Vraag ICT-leveranciers achter kritieke functies om hun lijst met toegang tot state en hun herstelbewijs, en leg een inzagerecht vast in het contract. | Classificeer snel. Eerste melding binnen 4 uur na classificatie als ernstig (uiterlijk 24 uur na ontdekking), tussenrapport binnen 72 uur na de eerste melding, eindrapport binnen een maand. |
| SOC 2 | Criterium CC6.1 gaat over logische toegang, inclusief wie state kan lezen. CC8.1 gaat over wijzigingsbeheer, inclusief hoe infrastructuurwijzigingen worden goedgekeurd en doorgevoerd. | Controleer of de infrastructuurpipeline en de stateopslag in de systeembeschrijving staan. Staan ze er niet in, dan zegt het rapport er niets over. | Een lek via te ruime toegang tot state komt waarschijnlijk als afwijking in het volgende rapport. |
| ISAE 3402 | De focus ligt op de financiële verslaggeving. State komt alleen in beeld via algemene IT-beheersmaatregelen voor toegang en wijzigingen, waar de infrastructuur het financiële proces ondersteunt. | Het rapport noemt infrastructure as code zelden. Vraag in het contract hoe wijzigingen aan het platform onder uw dienst worden beheerst. | ISAE 3402 schept geen meldplicht aan de auditors van gebruikers. Verwacht een afwijking in het volgende rapport en vraag in het contract om tussentijdse melding. |
Checked against: HashiCorp Terraform documentation on state, sensitive data, locking, backends, the S3 and azurerm backends and terraform init (Oct 2026), HCP Terraform and its data security page (Oct 2026), GitLab-managed state (Oct 2026), JFrog Terraform Backend repositories (June 2026), OpenTofu state encryption (Oct 2026), AWS S3 default encryption FAQ (Jan 2023), Microsoft Azure Storage encryption (Aug 2026), NIS2 Art. 21 and 23, DORA Art. 8, 9, 12 and 19, RTS (EU) 2025/301 on incident reporting time limits (Feb 2025), NCSC-NL (Aug 2026), AICPA Trust Services Criteria CC6.1 and CC8.1 (2017, points of focus 2022) · October 2026.
Gecontroleerd tegen: documentatie van HashiCorp Terraform over state, gevoelige gegevens, vergrendeling, backends, de S3- en azurerm-backends en terraform init (okt 2026), HCP Terraform en de pagina over gegevensbeveiliging (okt 2026), state in GitLab (okt 2026), JFrog Terraform Backend-repositories (juni 2026), OpenTofu-stateversleuteling (okt 2026), AWS S3 FAQ standaardversleuteling (jan 2023), Microsoft Azure Storage-versleuteling (aug 2026), NIS2 art. 21 en 23, DORA art. 8, 9, 12 en 19, RTS (EU) 2025/301 over meldtermijnen (feb 2025), NCSC (aug 2026), AICPA Trust Services Criteria CC6.1 en CC8.1 (2017, aandachtspunten 2022) · oktober 2026.