QR security: making safer connections

Security starts with the promise beside the code

A QR pattern does not tell a person who owns the destination or why it needs information. The surrounding sign, message and website supply that context. If a table card says View the menu, an unexpected bank login or software installer is a reason to stop. When you publish a code, make its purpose specific and keep that promise true after every edit. A technically working redirect can still surprise or mislead its audience.

This guide is primarily for people maintaining codes in a business, club or event. If you are deciding whether to trust a code you have encountered, use the quishing guide, which follows the scanner's decisions step by step. Neither guide can determine whether a particular unknown website is safe. URL shape, familiar artwork and a successful camera scan are not a substitute for checking the request and the organization behind it.

Separate visitor access from editing authority

The public QR URL belongs in the artwork. A guest management URL includes a secret fragment that grants administration of that code. Anyone holding the active credential can change where visitors go. Keep it in a password manager or controlled recovery file, not on a design board, shared screenshot, print brief or public support post. Giving a designer the public image does not require giving them the editing credential as well.

For ongoing work, decide whether an account provides a clearer ownership arrangement. Claiming a guest code into an account revokes its guest credential; handing someone an old copy of that credential afterwards will not restore their access. Make the handover deliberate, and check that the intended owner can sign in. The guest-management guide explains the recovery limitations before a project becomes dependent on a single saved link.

Keep a simple inventory instead of relying on memory

Give each code a useful name and record where it appears. North entrance poster is more actionable than QR final version three. Keep the public URL, current purpose, responsible person, destination and review notes together. Store private credentials separately. If the same code is copied onto several signs, record all those locations: replacing one compromised card will not address the others or an old image still circulating online.

Before a destination change, have the responsible person confirm that the new page matches the printed promise and is genuinely controlled by the intended organization. For a payment flow or account sign-in, use an independently verified contact rather than trusting a replacement URL delivered in a hurried message. This is a practical review step, not a claim that QRSwivo provides a two-person approval workflow; that feature is not implemented in the product.

Inspect the sign as well as the website

A publicly accessible sign can be covered by another sticker even when your own account is secure. During a venue check, compare the code and surrounding label with the approved version. Look for added layers, unexplained replacement cards or a destination inconsistent with the sign's purpose. Do not peel, alter or investigate equipment you do not own; ask the venue operator to examine it and use an independent route for any payment.

For your own site, make inspection part of an existing opening or event-setup routine so it has a responsible person. If a code appears wrong, stop distributing that version and preserve an ordinary photo of the sign for your own review. A digital pause prevents visits through your legitimate QRSwivo record, but it does not disable an attacker's unrelated sticker or website. Physical replacement and account controls solve different problems.

Know what the platform checks, and what it does not

QRSwivo restricts destinations to public HTTP or HTTPS URLs and rejects embedded credentials, local/IP destinations and its configured redirect hosts. It applies access checks, rate limits and production bot verification, and provides reporting and operator moderation. These safeguards address particular inputs and operations. They are not a malware reputation service, a guarantee about future page content, or automatic confirmation of the business identity behind a link.

A site can change its content without changing its URL, and a dynamic destination can change after printing. Yesterday's successful visit does not approve every future request. Avoid collecting more information than your stated task needs, and explain any legitimate move to another provider. If you add analytics to a destination, review that provider's data handling separately. QRSwivo does not currently provide scan statistics, optional advertising, or an assurance that external services follow a particular privacy policy.

When someone reports a suspicious connection

Collect the public QR identifier, the location of the sign, what the person expected, and what actually happened. Do not ask them to send passwords, card numbers or private management links. A QRSwivo abuse report enters an operator review queue; it does not automatically block the code or guarantee an immediate response. Administrators can inspect the current destination, which may differ from the destination at the time of the report.

If you control the suspect code, pausing it can stop new redirects while you review access and the destination. Use the destination-update guide to restore a known-good page only after the cause is understood. People who supplied sensitive information should use their bank's or organization's independently verified incident instructions. Avoid inventing a blanket cleanup procedure or promising that changing a QR destination repairs damage already done on an external website.

• State a clear purpose beside the code and provide an independent contact route.
• Protect management access and confirm ownership before handover.
• Inspect the physical placement and review destinations after changes.
• Prepare a way to pause, report and investigate without collecting more secrets.

References & further reading

• NCSC: QR codes and their risks
• FTC: recognizing and avoiding phishing