Normally you would let your test names do the talking. What I mean is, if you can have these two tests:
And if both of the above tests are an accurate description of the behaviour, then no, you don't need to write tests for all 25 possible states, because there are only 2 states that actually matter, "canceled" and "not canceled". In the actual implementation of "not canceled", of course, you will have to pick some specific other state. From a pure code coverage standpoint, you'll get full coverage this way.
On the other hand, you should also try to predict how the SUT might change. Maybe today there are 24 states that all behave exactly the same way, but three weeks from now the rules may change in a very subtle way that either breaks or isn't covered by the test you wrote today.
One thing I've sometimes done is, in the "negative" test, have a loop that enumerates all possible states, excludes the ones that don't apply, and verifies them each in sequence. That's the lazy way, but it's a little less flaky than just picking a state at random.
But most of the time I prefer to write Context/Specification style tests, which just remove this ambiguity altogether by making each possible state a separate test class, and yes, that does mean testing all 25 states, although there are numerous ways you could use inheritance or composition in the tests to reduce code bloat while still maintaining the tests for all states.
There's no rule, you can "get away with" whatever you want, it's just a question of how thorough you want your tests to be, which is probably going to depend on such things as how many other developers are working on the code, what the cost of each defect is to the business, how often you release, etc. If you're trying to do TDD or BDD, use context/specification for each state. If you're just trying to get half-decent code coverage, then just test one "on" and one "off" state.