AWS Organizations Stops Returning the account status Field This Month. Your Automation Won't Error, It'll Just Read Null.
This month, the status attribute in AWS Organizations API responses stops being returned. AWS deprecated it in September 2025 in favor of a new state attribute, and the one year clock runs out now: as of September 2026, status is gone from the payload.
If you have automation that reads account.status to decide whether an account is active, suspended, or pending, here is what happens when that field disappears. Nothing. No error, no exception, no failed API call. The DescribeAccount and ListAccounts calls still return a 200 with a valid account object. The object just no longer contains the field your code reads. In most languages that means account.status evaluates to null or undefined, your comparison against "ACTIVE" quietly returns false, and your governance logic takes a branch it was never supposed to take.
AWS Organizations is not a corner of the platform that a handful of people touch. It is the service large companies use to manage tens, hundreds, or thousands of member accounts: account provisioning, service control policies, guardrails, billing rollups, security baselines. The automation built on top of it is exactly the kind of code that reads an account's status to decide what to do, and it is exactly the kind of code that has been running untouched for two or three years. That is the code most likely to be reading status without anyone remembering it is there.
What actually changed
AWS added a new state attribute to member account information in September 2025 and deprecated the older status attribute at the same time. The two coexisted through the migration window. That window closes in September 2026, when the status value stops being returned in Organizations API responses.
The affected fields, in the shapes most integrations touch:
- The account object's
status, returned by calls likeDescribeAccount accounts[].statusin the list returned byListAccountsand the organization description- The status on member and non master accounts enumerated under an organization or an organizational unit
The replacement, state, exists specifically because AWS wanted to expose more granular account lifecycle information than the old status carried. So this is not a pure rename where the same values move to a new key. The new field can express states the old one could not, which means code that naively swaps the key name without checking the new value set can still end up mishandling cases it has never seen.
Why this fails silently instead of loudly
A removed response field is the quietest kind of breaking change there is, and it is worth being precise about why.
When AWS removes an endpoint, your call fails and you find out immediately. When AWS changes a required request parameter, your call is rejected and you find out immediately. But when AWS stops including a field in a response, the request still succeeds. The service has no way to know your code was going to read that field. It returns a valid object that happens to be missing one key, hands you a 200, and moves on. The failure is entirely on your side of the wire, in the line of code that reads the absent field, and it does not raise anything. It just gets nothing.
So your monitoring stays green. Your dashboards show successful API calls. Your error rate does not move. And somewhere, an account governance job reads status, gets null, decides the account does not match "ACTIVE", and skips it, or worse, treats it as needing remediation and acts on it. The gap between "the API call succeeded" and "the field I needed was in the response" is the whole problem, and nothing in the success of the call tells you that gap opened.
This is contract drift, and the changelog is not a safety net
Strip away the AWS specifics and this is the same failure behind every silent integration break. The live API stops matching the contract your code was written against, while still returning a valid response. AWS did this the responsible way, with a year of notice, a documented replacement, and a clear removal date. It is still contract drift, because the response your code parses in September no longer contains what it contained in August, and the 200 says nothing about the difference.
This is API contract drift, and knowing about the change in the abstract does not protect you from it. The announcement tells you status is going away. It does not tell you which of your Lambda functions, Terraform data sources, account vending pipelines, or compliance scripts actually read account.status. Finding those is a different task from reading the announcement, and it is the task that determines whether September is uneventful or not.
Contract testing helps at build time, but it validates your code against your assumptions about the response, and "status is always present" is exactly the assumption that stops being true this month. A test that builds a mock account object with a status field keeps passing, because the mock reflects the old contract the code assumes. The gap between "my fixture has this field" and "the live API still returns it" is the job of runtime monitoring that checks real responses instead of fixtures.
What to actually do
Whether or not your accounts have flipped to the new behavior yet, the defense is the same.
Search your infrastructure code and automation for every place that reads an account status from Organizations responses, including the indirect ones through Terraform data sources and SDK wrappers, and migrate them to state with an understanding of the new value set rather than a blind key swap. Validate the responses you get against a schema at the boundary, so a missing field fails loudly in your own system instead of turning into a null that flows downstream into a governance decision. Assert on the specific values you depend on, not just the success of the call, because a 200 from Organizations tells you nothing about whether status is still in the payload. And keep checking on a schedule, because this is one deprecation among many, and the next one is already announced somewhere in a changelog you have not read yet.
The lesson outlives the field
The AWS Organizations status field is one attribute in one service on one cloud. If nothing you run reads it, this particular change is not your problem. But the shape of it is everyone's problem, and AWS is the disciplined case here: a year of notice, a documented replacement, a fixed date. Even with all of that, the change that will actually bite is a field quietly vanishing from a response that still returns 200, breaking code that has run correctly for years, at a moment nobody flagged on a calendar. If this is what a well managed deprecation looks like from the outside, assume every other provider you depend on is doing the same thing with less warning, and that the only reliable way to know your integrations still match reality is to check the live responses, not the release notes.
Frequently asked questions
What is changing with the AWS Organizations status field in September 2026?
AWS deprecated the status attribute in AWS Organizations API responses in September 2025, replacing it with a new state attribute that carries more granular account lifecycle information. The two attributes coexisted during a one year migration window. As of September 2026, the status value is no longer returned in Organizations API responses, so code that reads it receives null or undefined instead.
Will my integration throw an error when the status field is removed?
Generally no. Removing a field from a response does not cause the API call to fail. Calls such as DescribeAccount and ListAccounts still return a successful response with a valid account object that simply no longer contains the status field. Code that reads the missing field gets null or undefined and continues, which is why this surfaces as incorrect behavior in governance and automation logic rather than as an obvious failure.
What should I use instead of status?
Use the new state attribute that AWS added to member account information. Because state was introduced to express more granular account lifecycle states than status did, you should review the full set of values it can return and update your logic accordingly, rather than performing a direct one to one key rename that assumes the same values.
How do I find everywhere my code depends on the status field?
Search all infrastructure and automation code for reads of an account status from Organizations responses, including indirect access through Terraform data sources such as aws_organizations_organization and through SDK wrappers. Then validate live responses against a schema at the boundary so a missing field fails loudly, and monitor real responses on a schedule, since a documented changelog tells you a field is going away but not which parts of your own codebase read it.