Use case · Traditional threat modeling

When the risk demands it, model it by hand.

Some systems warrant a deliberate, expert-led threat model. Run it in Reykur: model the design together on a live canvas, work from a library that knows exactly what applies, and walk away with a threat model that keeps working after the review ends.

payments-rewrite / Threat modelMTALiveShare
external · internettrust boundary · pci scope
Web clientexternal
Payments APIservice · oauth
Ledger DBdatastore · pii
Audit logdatastore
card data · tlswrites · piieventsmajatomas
Payments APIserviceoauthsessionin boundaryThreats4OAuth token theft via open redirectCredential stuffing on loginSession fixation across subdomainsControls3PKCE on authorization requestsRate-limit authentication endpoints
Before · Act I

You do not start from nothing.

Half your session used to go on redrawing a diagram everyone in the room already had. Three ways to skip the blank canvas.

The photo you already take

Upload the whiteboard photo

You already photograph the whiteboard. Upload it and get a real model instead of a dead JPEG: components, flows and boundaries resolved from the drawing.

Or the doc

Upload the design doc

An RFC, a spec or a user story becomes the first draft of the diagram. The room starts arguing about the design, not drawing it.

Or a few answers

Answer guided questions

No artifact at all? Structured questions about components, data, boundaries and deployment produce the starting model.

During · Act II

A canvas built for threat modeling.

The concepts you already work with, components, data flows and trust boundaries, on a live canvas with the whole team, backed by an assistant that answers and edits.

Reykur assistant · payments-rewrite
Assisted

A model you can talk to

Ask, and the assistant answers from the model. Tell it, and it edits the diagram: components, controls and boundaries, applied as the room talks.

Together

Real-time and multiplayer

Simultaneous editing with live presence, not sync on save. Everyone in the review works the same model, wherever they sit.

No re-training

Your method, in hours

STRIDE sessions, DFD reviews, boundary walks: run them the way your team already does, with the tooling that was always missing. The setup, the write-up and the follow-through stop eating days, and the result is both more accurate and faster.

During · Act III

Threats fire on conditions, not on a model's mood.

Every threat in the library carries an explicit, inspectable condition. A reviewer in the room can read it, and argue with it.

Grounded

Built on leading frameworks

OWASP ASVS and other established standards, restated as controls with STRIDE and CWE on every threat. Openly attributed, never invented in the moment.

Deterministic

Only what applies to you

A system with no passwords will never see a password threat, and a system with them will never miss one. A condition either holds or it does not. Generic AI advice cannot make that promise.

Honest

Levels never hide threats

The assurance level filters which requirements are assigned, never which threats are emitted. A matched threat above the target is still a real risk, and is still reported.

Payments APIyour system & its features
password authoauth2file uploadpublic api
Added to the model
Credential stuffing3 controls
OAuth redirect hijack2 controls
Malicious file content2 controls
Rate-limit bypass2 controls
Discarded
XML external entitiesno xml parsing
SMS OTP interceptionno sms-based auth
After · Act IV

The meeting ends. The model does not.

A sharper session while everyone is in the room. Afterwards, the model, the decisions and the report keep working.

The report, generated from the model

Executive summary, architecture, threat register, controls, risk posture and signed acceptances. Sixteen sections produced directly from the model, exportable as PDF, CSV or a password-protected share link.

Every session feeds your security context layer

Components, threats, controls and accepted risks flow into a living, organization-wide security context layer. It informs the next review, drives risk decisions across teams, and gives security leadership a live picture of posture instead of a folder of stale documents.

After · Act V

The manual model does not stay an island.

Three reasons the review keeps paying off.

Continuous

The same model goes continuous

You built it by hand because this system deserved it. From the next sprint on, it maintains itself: the continuous loop keeps it current, and your coding agents' plans get checked against it.

Owned

It has named owners

Architecture, security, engineering and product each hold a defined seat on the model: who can edit, who can accept risk, who can only read. Every threat has an owner, and every accepted risk has a name against it.

Org-wide

It rolls up into org-wide context

One review tells you about one system. Twelve of them, aggregated into risk scores, trends and a cross-project graph, tell you whether the program is working.

organization · risk overview12 models
Every control traces to
OWASP ASVS 5.0STRIDECWESOC 2

The room was never the problem.The aftermath was.

See a real design review run end to end, from whiteboard photo to signed-off model to a live org view, in 20 minutes.

Get early access

Get early access

Be among the first to try Reykur and help shape continuous product security.

No spam. We'll only email you about Reykur.