What You See Is What You Sign

Expanded Definition

What You See Is What You Sign, or WYSIWYS, is a transaction integrity pattern that ensures the approval interface matches the exact data that will be executed. It matters wherever a user, customer, or operator is asked to authorise an action with legal, financial, or operational impact. In practice, WYSIWYS is not a single product feature but a design property spanning the application, browser, rendering layer, and signing workflow.

For NHI Management Group, the key distinction is between display integrity and intent integrity. A system may authenticate a user correctly and still fail WYSIWYS if an attacker can alter a payment amount, destination address, policy setting, or signing payload after review. That is why WYSIWYS is often discussed alongside controls for secure input handling, tamper resistance, and strong transaction binding, such as those reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls and browser-security guidance from OWASP.

Definitions vary across vendors because some describe WYSIWYS as a signing assurance property, while others treat it as a UI security requirement or transaction confirmation control. The common thread is that the approved content must be cryptographically or operationally bound to the visible content, not merely suggested by it. The most common misapplication is assuming a confirmation click equals WYSIWYS, which occurs when the displayed summary is not independently locked to the signed payload.

Examples and Use Cases

Implementing WYSIWYS rigorously often introduces design and validation overhead, requiring organisations to weigh stronger user assurance against more complex engineering, testing, and exception handling.

• Online payments: the interface displays the final payee, currency, and amount, and the signing event is bound to those exact fields so a hidden script cannot modify them after review.
• Crypto wallet approvals: a transaction preview must match the on-chain call data, because a mismatched interface can trick a user into signing a transfer they never intended.
• Enterprise approvals: a privileged workflow shows the specific change request, target system, and rollback scope before the approver authorises it, reducing ambiguity in high-risk changes.
• Document signing: the signer sees the rendered document and the hash-anchored version being committed, limiting the risk of post-review substitution.
• Identity assurance flows: when a user confirms a recovery or enrolment step, the exact account and action should be visible so the approval cannot be replayed against a different object.

For teams designing transaction-review workflows, WYSIWYS is easiest to evaluate when the UI, the backend, and the signed object are all independently verifiable. Browser hardening and secure rendering patterns recommended by OWASP Browser Security guidance help reduce tampering paths, but the core requirement is stronger than presentation security alone.

Why It Matters for Security Teams

WYSIWYS is a control against silent content substitution, which is one of the most damaging failures in user-mediated security flows. If a team treats visual confirmation as proof of integrity, attackers can exploit script injection, malicious extensions, reverse proxies, compromised SDKs, or UI redress attacks to alter what the user thinks they approved. That risk spans payments, privileged administration, identity recovery, and agentic AI actions where an autonomous agent may present a summary for human approval.

This is especially relevant when a human is the last control before a secret, token, certificate, or high-impact command is committed. In identity-heavy environments, WYSIWYS supports stronger approval semantics for recovery, enrolment, and delegation workflows, where the wrong object being signed can become a durable access failure. Security teams should map WYSIWYS expectations to transaction binding, secure session handling, and tamper-evident auditability rather than assuming authentication alone is enough.

Organisations typically encounter the consequences only after a fraudulent transfer, mis-signed change, or recovered account has already been executed, at which point WYSIWYS becomes operationally unavoidable to investigate and contain the mismatch.

Related resources from NHI Mgmt Group

• What breaks when organisations cannot see their non-human identities?
• How do you know if agent identity controls are actually working?
• How do you know if Oracle access governance is actually working?
• How do you know if Oracle SoD evidence is actually working?