A reviewed threat model annotates every component with the same operator credential - what do you conclude?

## The shape of the finding Boundary placement rests on comparison: you look for a point where the principal changes, or where the same principal holds materially different privilege, and you draw the boundary there. A diagram in which every element carries the same label defeats that method by construction. There is nothing to compare, so the mechanical procedure yields zero boundaries - and an inexperienced reviewer reports a clean model. The correct reading is the opposite. A single credential shared across functions with genuinely different trust needs has not removed the boundaries; it has removed your ability to *see* them, and it has handed every holder of that credential the union of everything the credential can do. ## The worked case A utility runs a head-end system that talks to a fleet of smart meters. Two very different consumers reach the meters: a field-technician application used on laptops in vans, for commissioning and diagnostics, and the billing service that collects consumption and issues commands affecting what customers are charged. Both authenticate to the meter platform with one operator credential, because that is what the platform issues. Drawn faithfully from implementation, the diagram shows two boxes and two flows carrying identical annotations. No edge crosses a privilege change. Now state what is actually true: a technician's laptop, or a vendor engineer who supports that application, holds an identity that can do everything billing can do. The adversary here is a compromised operator or vendor technician - someone with legitimate but narrow business need - and the assets are metering revenue and the physical process the meters participate in. Neither of those risks is visible on the flattened picture. ## Modelling intent alongside grant The technique that rescues the review is to keep two layers. Draw the boundary where trust *should* change - between field work and billing - and annotate the crossing with what is presented today: the same credential on both sides. The boundary is now on the diagram as an assertion about the system's trust needs, and the annotation is the deviation. Everything downstream of that - which threats you enumerate at the crossing, how you rate them, what you propose - hangs off the boundary, so it must exist even while the implementation contradicts it. This is also what stops the conversation from stalling on feasibility. Whether the platform can issue two credentials this quarter is a delivery question. Whether trust changes between a van and a billing run is a design question, and it has already been answered. ## The leadership call At this point the decision is not technical. Splitting principals across a deployed fleet is expensive, involves a vendor, and competes with everything else. Three responses are legitimate: - **Split now**, if the blast radius of the shared credential over the most valuable asset justifies displacing other work. The ordering argument is the strongest one available: a shared principal with command authority over revenue-bearing devices outranks narrower findings regardless of how the individual threats were rated. - **Split the highest-value slice**, separating the credential used for commands that affect money or physical state from the one used for read-only diagnostics, and accepting the rest. - **Accept, and record.** Write the deviation down with its consequence stated in the model itself, so the next review inherits it rather than re-deriving it, and so the boundary stays on the diagram as an unmet intention rather than quietly disappearing. What is not legitimate is silence. An accepted risk that lives only in someone's memory is indistinguishable, a year later, from a risk nobody noticed. ## When the constraint is immovable Sometimes the platform simply cannot issue more than one identity. Then the honest model treats every holder of that credential as one trust zone at the worst-case privilege the credential carries, annotates the constraint on the diagram so no reader assumes otherwise, and shifts the argument to who is allowed to hold it and how tightly that population is controlled. That is a real answer, and it is stronger than a diagram that quietly implies separation the system does not provide. ## The failure mode to name The error this question is really probing is the inference from *the diagram shows no privilege change* to *there is no boundary here*. The annotation method is only as good as the difference it can detect, and uniformity destroys difference. A lead is expected to notice when the method has been blinded rather than satisfied.