Security & Architecture
In Personal Use mode, your vendor credentials live in your device's Keychain and every API call goes directly from your phone to your vendor — CrowdStrike, Microsoft, or AWS. There is no PocketSOC server in the data path. This page explains the architecture behind that claim and how we verify it.
Two modes, two architectures
PocketSOC runs in one of two operating modes, and they have deliberately different security architectures. Knowing which mode you use tells you exactly where your credentials live and what our servers can see.
Personal Use
For individual practitioners connecting their own vendor tenants.
- Vendor API credentials are stored in the device Keychain only. They are never uploaded to, cached by, or recoverable from PocketSOC servers.
- Every vendor API call goes directly from your device to CrowdStrike, Microsoft, or AWS. No PocketSOC server sits in the data path — not as a proxy, not as a relay.
- A built-in NetworkGuard check refuses any vendor base URL that points at a PocketSOC or WeaveHub host, as a belt-and-suspenders defense against misdirected credentials.
- This is an architectural property, not a policy: there is no code path that sends a Personal Use credential to us.
Organization
For teams managed through the PocketSOC Portal.
- Vendor credentials are configured by your portal administrators and encrypted at rest with AES-256-GCM on our backend.
- Role-based access control governs who in your organization can manage devices, groups, and vendor configurations.
- Push notification delivery, on-call schedules, and audit logging are handled server-side.
- For the full enterprise security posture — infrastructure, access control, secure development lifecycle, and responsible disclosure — see the Trust Center.
What our servers never see (Personal Use)
Because Personal Use mode talks to your vendors directly, entire categories of data never reach our infrastructure:
- Your vendor API credentials — client IDs, client secrets, tenant IDs, AWS access keys
- The contents of your detections, alerts, and findings
- Your vendor API traffic — requests and responses flow device-to-vendor over TLS
What our servers do see for Personal Use accounts:
- Licensing and subscription state, keyed to an opaque Sign in with Apple identifier — never your password, name, or email scopes
- Anonymous, opt-in analytics events (screen views, feature usage) with no alert content, hostnames, or credentials — and you can turn these off in Settings
iCloud Keychain, stated plainly
Personal Use credentials are stored in the iOS Keychain with iCloud Keychain synchronization enabled. That means: if you have iCloud Keychain turned on, Apple may sync those credentials — end-to-end encrypted by Apple, unreadable by Apple's servers in usable form and unreadable by us — to your other devices signed into the same Apple ID.
They sync through Apple's infrastructure only. They never sync to PocketSOC. If you prefer credentials to stay on a single device, disable iCloud Keychain in iOS Settings; the app works identically either way.
Least privilege by design
PocketSOC works with whatever scopes you grant it — so grant the minimum. Viewing detections is free in Personal Use mode and requires only read scopes. Our recommendation:
- Start read-only. Create a dedicated API client in your vendor console with read-only scopes (detections/alerts read) for your first connection. You can browse, triage, and evaluate the entire app with nothing but read access.
- Add action scopes only when you need them. Response actions — acknowledging, closing, or containing — are part of the Pro subscription. Add write scopes to your API client if and when you start using them.
- Rotate on your schedule. Credentials are created and revoked in your vendor console. Revoking them there cuts off the app instantly, with no PocketSOC involvement required.
Per-vendor scope guidance is on each integration page.
How we test these claims
The zero-credential-egress property is verified, not assumed. Our security program includes:
- STRIDE threat modeling — iterative threat-model rounds across the mobile apps, portal, and backend, with findings remediated and re-verified in follow-up rounds
- Network-capture audits — release validation for Personal Use mode includes proxying all app traffic and confirming that credential-bearing requests go only to vendor domains. The pass criterion is zero credential bytes in any request to pocketsoc.com or weavehub.app — across onboarding, refresh, response actions, and background fetch
- Security regression testing — automated vulnerability scanning and static analysis integrated into the release process
- Penetration testing — production penetration tests against the portal and backend, with remediations verified live
- Telemetry audits — crash reports and analytics are checked for credential and secret leakage, with redaction patterns covering tokens, keys, and passwords
See it for yourself
Try Demo mode without connecting anything, or connect a read-only API client and watch your own network traffic.
Related: Privacy Policy · Trust Center