Privacy and Data Standards
Version 1.1 · June 2026
Canonical privacy posture (identical in the iOS app, paywall, and marketing site): Unknown-sender messages are immediately converted to coded fingerprints; correlation happens at the sender and message-content level only. No user identity is attached on personal/consumer plans - it feeds anonymous campaign intelligence. Only on a corporate plan with a company-managed device is there user-attributed insight into who is being targeted. On Personal, nothing leaves your device.
SmishAlert is a recipient-side security company. We protect the people who receive messages, not the brands attackers impersonate. That position has architectural consequences. We run on the recipient's device, evaluate content the recipient owns, and operate in a layer most security tools do not reach. That position carries meaningful responsibility.
These standards describe how we treat recipient data. They define what stays on the device, what leaves the device, what we never collect, and what employers can and cannot see. They reflect our operating principles. Specific obligations are defined in customer agreements and our Privacy Policy.
Our Core Principles
Five principles guide every product decision we make and every customer agreement we sign.
Principle 1: Protect the Recipient First
Our customer is the buyer. Our user is the recipient. When those interests conflict, the recipient's privacy comes first. A buyer cannot purchase visibility into an employee's personal messages, and we will not configure the product to provide that visibility.
Principle 2: Process Locally, Transmit Sparingly
Smishing detection always starts on the device. On Personal and Report-Only plans, the full classification path stays on the phone — nothing leaves automatically. On Unknown Guard (consumer) and Workforce (corporate) plans, unknown-sender messages from numbers not in the user's contacts may be sent to SmishAlert using Apple's Message Filter network defer API for server-assisted screening. At capture, that traffic is converted to coded fingerprints (plus an ambiguous-content snippet only where the fingerprint is inconclusive). User-initiated reports are a separate, explicit full-content path covered below.
Principle 3: Background Telemetry Is Fingerprints, Not Contents
Background telemetry transmits fingerprints: hashed structural representations of normalized messages, template skeletons, sender metadata stripped of raw identifiers, on-device verdicts, and coarse timestamps. These signals are useful for detecting attack campaigns across our user base. These signals are structurally incapable of reconstructing a message. User-initiated reports are a separate path with their own rules, covered below.
Principle 4: Personal and Managed Devices Get Different Policies
A personal or BYOD device is not a managed device. Our admin console treats them as distinct policy axes. Personal and unconsented BYOD devices default to minimal telemetry and zero content disclosure. Managed devices and consented BYOD devices may permit richer signal under explicit, logged organizational policy. The user always has visibility into which mode applies to their device and what that mode permits.
Principle 5: Transparency Over Assertion
Recipients can see what is collected about them. Admins see aggregate intelligence, not individual message narratives. A current list of subprocessors is maintained on our Trust page. Data flows are documented there and in this policy. Trust is earned through auditability, not assertions.
Off-Device Unknown-Sender Review (Unknown Guard / Workforce)
This section describes automatic review of unknown-sender SMS and iMessage on iPhone when the user has subscribed to Unknown Guard or is enrolled in a corporate Workforce deployment with Message Filtering enabled.
Apple network defer
iOS delivers unknown-sender messages to SmishAlert through Apple's IdentityLookup Message Filter extension and its network defer contract. The extension runs on-device first; when the plan requires server-assisted review, iOS may POST to www.smishalert.ai/api/ios/message-filter/network. This is separate from user-initiated Report Junk, share-sheet, or screenshot submissions.
Fingerprints, not full inboxes
Unknown-sender messages are immediately converted to coded fingerprints at capture. Correlation happens at the sender and message-content level only — not by linking messages to a user's name or account on consumer plans. We do not read messages from contacts or known senders through this path. Full message bodies are not retained as part of background processing; ambiguous cases may include a minimal snippet only where the fingerprint alone is inconclusive.
No user identity on consumer plans
On the consumer Unknown Guard plan (App Store, non-managed device), automatic unknown-sender review feeds anonymous campaign intelligence. Your name, email, and SmishAlert account are not attached to those fingerprints. On a corporate company-managed device with Workforce mode, user-attributed insight may apply because the employer provisioned and disclosed the deployment.
Personal plan: on-device only
On the consumer Personal plan, network defer is disabled. Classification runs entirely on-device and nothing leaves the phone automatically. See our Trust page for a plan-by-plan comparison.
What We Will Never Do
The following commitments are absolute. They are not subject to customer override, contractual exception, or admin configuration.
Message Content
Message body content is among the most sensitive data on a phone. We architect around that. On Personal and Report-Only plans, message content leaves the device only when a user explicitly reports it. On Unknown Guard and Workforce plans, unknown-sender messages use the fingerprint path described above; user-initiated reports remain a separate full-content path.
No automatic off-device transmission on Personal / Report-Only
On Personal and Report-Only plans, background processing never transmits unknown-sender message bodies off the device. Classification happens on-device, and only user-initiated reports use the full-content path.
Message bodies are stored only when reported
We do not retain message bodies on our servers as part of background processing. The only message content stored on our infrastructure is content the user has explicitly reported, or content reviewed under an explicit and logged managed-device policy. Both paths are visible to the user.
No reading outside the classification path
Our message filter extension exists to evaluate inbound messages for smishing. It does not scan, log, or analyze messages for any other purpose. There is no marketing analytics layer, no ad targeting, and no secondary use of this classification path.
No sale or onward transfer of message data
Recipient message data, fingerprints, reported content, and behavioral data are never sold, shared with third parties, or repurposed beyond the scope of the customer agreement.
Reporting
User-initiated reporting is the one path by which message content leaves the device. We are explicit about how that path works.
Reporting is always user-initiated
We never report a message on a user's behalf without their action. There is no auto-report mode. There is no admin-triggered reporting against a specific user's device. There is no silent background reporting.
Reported content is transmitted and stored
When a user reports a message, the message body, sender metadata, and contextual data are transmitted to our infrastructure and stored for campaign analysis and threat intelligence. Storage follows the retention schedule documented in our Privacy Policy.
Reported content informs aggregate intelligence
Reported messages contribute to campaign intelligence and detection quality. Individual reports are not shared with other customers as identifiable content. Patterns and fingerprints derived from reports may inform protections delivered to other users.
Identity and Device Data
We collect the minimum identity and device data required to operate the product. Nothing more.
No address books or contact lists
We do not request, access, or transmit the recipient's contact list. Sender identification is performed against message metadata, not against the user's social graph.
No raw phone numbers read from the device
The user's phone number is sourced from our authenticated identity layer, not read from the device OS. Permissions like READ_PHONE_STATE and READ_PHONE_NUMBERS are not requested.
No cross-tenant identity linking
We do not link a recipient's identity across employers, organizations, or tenants. A user who moves between SmishAlert customers is not tracked across that boundary.
Minimum necessary permissions
Every permission requested is documented, mapped to a specific product function, and removed when no longer required. We have removed permissions in past releases when the product no longer needed them.
Admin Visibility
The admin console exists so security teams can see attack campaigns. It does not exist so employers can read employee message content.
No individual content disclosure from personal or unconsented BYOD devices
Admins never see the body of an individual message from a personal device or from a BYOD device without explicit user consent. Aggregate campaign intelligence is the only output.
No silent policy changes
Changes to what is collected on a user's device are surfaced to the user in the app. A managed-device policy that expands collection cannot be activated without user visibility.
No persistent per-user message reading rights
There is no admin role anywhere in the product that grants standing access to read individual recipient messages. Incident-level content review on managed devices is logged, scoped, and time-bounded.
Reporting and telemetry are separate decisions
A user reporting a suspicious message is one decision. Background telemetry collection is another. These are configured separately, surfaced separately, and consented to separately.
Data Lifecycle
The data we do collect has a documented life and a documented end.
Documented retention and destruction
Telemetry, fingerprints, and operational logs follow a published retention schedule. Customer data is destroyed at agreement termination according to that schedule.
No model training from background telemetry without consent
Background telemetry is not used to train models or improve our product without explicit, separately-granted opt-in. The default is no. User-initiated reports are treated separately and may be used to improve detection for all users, as covered in the Reporting section.
Listed subprocessors only
We publish the list of subprocessors involved in our data flow. No new subprocessor is added without notice to customers.
These standards reflect what the product does today and what we commit to maintaining as it grows. We expect to update them as the product evolves. Versions and dates are tracked above.