Security

1. Security by what we do not hold

The strongest control in Boardhop is architectural: most of your data never reaches us, so there is nothing of yours to lose.

• The app talks to Azure DevOps directly from the device, with the user's own token. Work items, comments, code, diffs and wiki content never transit our servers.
• The relay reads a webhook payload in memory only, to decide who should be notified, and persists nothing from it.
• What reaches Apple and Google is a pointer: organization, event type, item type and id, actor display name, a verb, a title of at most 80 characters, and a link. The pointer type is enforced at the gateway boundary; anything else is rejected.
• The device enriches the notification itself, fetching the detail with the user's own credentials, before it is displayed.

2. Credentials

• Azure DevOps tokens live in the iOS Keychain or the Android Keystore and are never transmitted to us — except once, at device registration, where a token is used to confirm organization membership and then discarded. It is never written to storage or to a log.
• Apple and Google push credentials exist on the push gateway only, with restricted file permissions, mounted read only, never copied into a container image or a backup.
• Each customer organization has its own webhook secret, verified on every inbound request.
• Logs redact tokens and secrets.

3. Infrastructure

• The relay runs in the European Union, behind TLS terminated by a reverse proxy with automatic certificate renewal.
• Administrative access is key-based SSH only. Password authentication and direct root login are disabled. The host firewall exposes only what the service needs.
• Tenants are isolated: every registration and every inbound event carries its organization identity, and per-organization rate limits keep one customer from affecting another.
• Operating system and dependency updates are applied on a regular cadence.
• Organizations that cannot accept event metadata leaving their tenancy can run the same relay themselves; it forwards pointers to our gateway over a revocable per-deployment key.

4. The app

• Sign-in uses Microsoft Entra ID through the system browser or the Microsoft Authenticator app. Boardhop never handles your password and supports your tenant's multi-factor and conditional access policies.
• Boardhop requests delegated Azure DevOps permissions only. It can never see or do more than the signed-in user already can.
• The offline cache is stored in the app's private container on the device and is namespaced per account; signing out deletes it.
• Store builds contain no analytics, advertising or crash reporting SDK. Diagnostic screens exist only in internal builds.
• Releases are signed and distributed only through the App Store and Google Play.

5. Reporting a vulnerability

Email security@boardhop.dev. Tell us what you found and how to reproduce it. We acknowledge within two business days, keep you updated, and will credit you when a fix ships unless you would rather we did not.

Please do not run automated scans against the relay, do not access another organization's data, and give us reasonable time to fix something before you publish it. We will not pursue legal action against research done in that spirit. There is no paid bounty programme today.

6. For security questionnaires

The short answer to most questions is that the data the question is about does not exist on our side. Section 4 of the data processing addendum lists exactly what we process, and the subprocessors page lists everyone who touches it. If your process needs more, write to security@boardhop.dev and we will answer your questionnaire directly.

7. Certifications

Boardhop does not hold a SOC 2 or ISO 27001 certification today. We would rather say so plainly than imply otherwise. If your procurement requires one, tell us — it is the kind of thing a committed customer moves up the list.