When arrival order and actual order diverge
An event ordering guarantee states whether a system promises to process events in the order they actually happened, or makes no such promise and allows events to arrive and be processed out of sequence. Many distributed and event-driven systems deliberately don't guarantee strict ordering, because guaranteeing it is genuinely expensive and unnecessary for most of what the events are actually used for downstream.
This becomes a real authorization problem specifically when a decision depends on sequence: a permission-revoked event that arrives and gets processed after a later action-attempted event it should have preceded can leave that later action authorized under a permission that, in the actual timeline of what happened, no longer existed by the time the action occurred at all.
Knowing explicitly whether the guarantee actually holds
A system making sequence-dependent authorization decisions needs to know explicitly, and design around, whether its event pipeline actually guarantees ordering, rather than quietly assuming events simply arrive in the order they happened because that's the intuitive default expectation. Where that guarantee genuinely can't be provided cheaply, the design has to compensate some other way — timestamping events with their actual occurrence time rather than their arrival time, and evaluating decisions against that occurrence time rather than processing order.