Security principles

These rules apply to every connection with wawa. Integration guides add specifics on top.

• Encrypted transport. We typically prefer HTTPS, over the internet and inside a Site-to-Site VPN. For self-signed or internal-CA certificates, we require your internal root CA certificate so our servers can verify your targets. If a system speaks another TCP- or UDP-based protocol, we can add support for it.
• Public targets are yours to secure. If you publish an integration target on the internet, hosting and securing it is your responsibility; see Public connectivity.
• Least privilege. Credentials you create for wawa are read-only unless the integration writes back, and scoped to the specific system.
• Dedicated credentials. Create a service account used only by wawa. Never share admin or personal logins with us or between systems.
• Strong, random secrets. Use generated secrets of at least 20 characters and rotate them at least annually, or immediately if compromise is suspected.
• Allowlist our egress IPs on anything you expose to the internet for wawa. See Egress IPs.
• Secrets travel over a secure channel. We exchange credentials and VPN configuration through 1Password or another secure channel you agree with us, never in plain email or chat.
• Protect staff sign-in. Staff can sign in with Google or Microsoft and turn on two-factor authentication; see Single sign-on.
• Verify what we send you. Every webhook is HMAC-signed. Verify the signature before trusting a delivery; see the Webhooks Reference.
• No wawa agents on your network. Private integrations terminate at your firewall; wawa does not install or run its own software on your machines. Some integrations rely on software you operate yourself, such as a DICOM server or a printer driver; each guide says so.

Security, privacy and compliance documentation is available in the wawa Trust Center.