What is the Repudiation threat in STRIDE, and which security property does it violate?

## The letter and the property STRIDE names six threat categories, and each one is the negation of a security property you wanted: | Letter | Threat | Property it violates | |---|---|---| | S | Spoofing | Authentication | | T | Tampering | Integrity | | **R** | **Repudiation** | **Non-repudiation** | | I | Information Disclosure | Confidentiality | | D | Denial of Service | Availability | | E | Elevation of Privilege | Authorization | Repudiation is therefore not "someone broke in". It is: **an action happened, and afterwards nobody can prove who caused it or what it was.** The threat runs in two directions - a party denies something they really did, and a party asserts something that never happened - and both are won by the same thing: evidence a neutral third party would accept. ## Threat, vulnerability, risk, control Keep the four straight, because repudiation is where they blur most easily. - The **threat** is "the trader will deny placing the order". - The **vulnerability** is the concrete flaw that makes the denial credible - the order record holds no authenticated principal, or the store lets the row be updated in place. - The **risk** is the rated consequence: a disputed six-figure trade you cannot defend, plus a regulator asking how you close out disputes at all. - The **control** is the answer: authenticate the actor, record the action with the fields that settle a dispute, and put the record somewhere the actor and their administrators cannot edit. ## Where it lands in a model When you walk a data-flow diagram, repudiation is the question you ask of **processes** ("which actions can this component take that someone would later want to deny?") and of **data stores** ("can this store's history be rewritten or discarded so that what it said at the time is unknowable?"). A store whose only representation of a fact is the current row has no history to appeal to; once it changes, the previous state is a matter of memory and assertion. Repudiation clusters wherever an action is **consequential and contested later**: money moves, a clinical result is released, a customer-visible configuration is changed, a privileged operator runs something in production, a record used for regulatory reporting is edited. ## Identity design is half of it A very common finding is not "there is no log" but "the log names something that is not a person". Shared administrator accounts, a generic `svc-deploy` credential used by five pipelines, a support tool that acts as a single system identity on behalf of any agent - each of these makes every downstream record unattributable, no matter how carefully the logging was implemented. You cannot log your way out of an identity model that cannot distinguish actors. That is why the answering control family for R is **authentication plus audit**, in that order: the record can only be as specific as the identity that produced it. ## Logs are not automatically evidence Saying "we ship everything to a central log platform" does not close a repudiation finding. Evidence has requirements that ordinary application logging usually does not meet: a named authenticated principal, the full parameters of the action rather than a summary line, trustworthy time, a store outside the acting party's administrative control, a retention period longer than the window in which disputes arise, and the ability to actually retrieve the entry months later. A log written mainly for debugging is optimised for none of those. ## Why teams under-rate it Repudiation findings get deprioritised more than any other STRIDE letter, because the harm is deferred and hypothetical - nothing is stolen today, nothing is down today, and the cost only arrives during a dispute, an investigation or an audit. That is also why it is worth calling out explicitly in a model: it is precisely the class of finding that never generates its own pressure until the moment you need it and it is not there. One more consequence worth writing into the model: once you build an evidence store, that store becomes an asset in its own right, and attracts attention from exactly the people it holds accountable. Its own integrity and its own access control are part of the design, not an afterthought.