FirstSignal Privacy Policy

Effective date: 9 November 2026
Last updated: 10 November 2026

FirstSignal ("the app") is published by FirstSignal, an independent developer based in New Zealand ("we", "us"). This policy explains what information the app handles, where it goes, and your choices. It applies to the FirstSignal Android app distributed through Google Play.

The short version, in plain facts:

• There is no FirstSignal account. We do not receive your lists, settings or the products you enter. Once a day the app downloads one small settings file from firstsignalcyber.com, which we log without your IP address (section 2.1). The one thing the app can send to a FirstSignal server is optional anonymous usage counts, which are off until you turn them on (section 2.9).
• Your lists, settings and the products you enter are stored on your phone. They leave it only if you back them up or move them to a new phone (section 1).
• The phone fetches public feeds directly from their publishers. Like any website, they see your IP address and the time of the request.
• Lookups that name one CVE send that CVE ID: when you open one, and in the background for CVEs your phone already holds or you watch (section 2.2). Your product list is never sent.
• Google Play handles purchases (section 3).
• The on-device AI model is provided by Google through ML Kit and AICore. Google says ML Kit sends diagnostic and usage information to Google (section 2.4).
• The app contains no advertising. Its only analytics are the optional usage counts, which are off by default.

1. Information stored on your phone

The following is created by you or by the app and is stored only in the app's private storage on your phone:

• Your stack: the products, vendors, versions and tags you add, and your stack profiles.
• Your settings: role, sector and region choices, notification settings (quiet hours and the briefing time), your alert rules (the vendors, products, severity and other conditions each rule matches, and the sound you pick for it), lane preferences, field mappings for detection rules, and whether Send includes why an item matters to you. A sound you pick is stored as a reference to a sound already on your phone; the sound itself is not copied.
• Your own feeds: the feed addresses, names and tags you add. A feed address that contains a token is encrypted with a key held in the Android Keystore.
• Your triage history: items you save, set aside for later, dismiss or send, watchlist entries, and the history of signals and lead-time records.
• Cached public data: CVE records, advisories, news titles and snippets, exploitation signals and scores downloaded from public sources.
• API keys you enter for optional sources (NVD or VulnCheck; section 2.3). Keys are encrypted with a key held in the Android Keystore on your device.
• On-device AI output: summaries and drafts generated on your phone. Text you give the on-device model is processed on the phone and is not sent to us or to any cloud AI service.

None of this information is sent to us. The optional usage counts (section 2.9) send ranges and totals about use, never this content.

Your own lists (the products you enter, Saved, Later and Dismissed with their dates and notes, alert rules, your own feeds, your watchlist, industry and region, and settings) can move to a new phone in three ways, all started by you. API keys, feed addresses that carry a token, downloaded records and news, models and the app's encryption keys never leave the phone this way.

• A backup file you make in Settings, Back up and restore. It is locked with a passphrase you choose and saved where you pick. FirstSignal cannot open it or recover the passphrase.
• Android's phone-to-phone transfer (by cable or local Wi-Fi, for example when you set up a new phone). The app gives Android one file with your lists, and nothing else. It goes from your old phone to your new one and does not pass through FirstSignal.
• Google backup, only if you turn on "Back up my lists with Google" in Settings, Back up and restore. It is off until you do. Android then includes the same single file in your Google backup. Google stores it under your Google Account and locks it with your phone's screen lock; it is not stored with, or readable by, us, and it is nothing we receive. If your phone has no screen lock, nothing is backed up. Turning the switch off stops new copies; to remove a copy Google already holds, use your Google backup settings. A phone managed by an employer may block backups.

After a transfer or a restore from Google, FirstSignal merges the restored lists into the new phone the first time you open it. What is already on the new phone is kept. Add your API keys again there.

The lists file is kept on the phone in the app's private storage; Settings, Data on this phone, Delete all data removes it. A copy that Google already holds is not removed by that; delete it in your Google backup settings.

Uninstalling the app, or using Android Settings, Apps, FirstSignal, Storage, Clear storage, permanently deletes all of it. The app also offers Settings, Data on this phone, Delete all data.

Information leaves the device only when you choose to share it. See section 2.6 for what Send and Copy contain. What you share, and where, is under your control and subject to the receiving app's policies.

2. Network requests the app makes

FirstSignal connects directly from your phone to the services below. We do not operate a server in between. The two exceptions are the daily settings file (section 2.1) and the optional usage counts (section 2.9). Like any internet request, each request reveals your device's IP address, the time, and basic technical information to the service you connect to. Requests to the built-in sources carry the app's user-agent string, FirstSignal/<version> (+https://play.google.com/store/apps/details?id=app.firstsignal). Those services handle that information under their own privacy policies.

Every request uses HTTPS and the app refuses plain HTTP. Built-in sources follow at most five redirects, and only to the host each source is configured for. The app checks every address a source's host name resolves to, before connecting and on every redirect, and never connects to a source at an address on your local or corporate network.

If your phone or your organisation's network sets a proxy, requests to the built-in sources go through that proxy, which usually sits at a private address on your network. The proxy operator (for example your employer's IT team) can see which hosts the app contacts and when; the content stays encrypted by HTTPS unless the proxy is set up to inspect it. Your own feeds never use a proxy (see section 2.5).

2.1 Bulk public data (your products are not part of the request)

By default the app downloads whole files or feeds and does all matching on the phone. These requests do not contain your products, versions or settings. The one exception is the CVE record refresh in the first item below and in section 2.2.

• CVE List change file and CVE records (CVE Program, raw.githubusercontent.com). The change file is the same for everyone. Records for the CVEs in it that your phone already holds, or that are on your watchlist, are refetched by ID in the background, so the host sees your IP address and that CVE ID (section 2.2). Records for CVEs named by the exploited-vulnerabilities catalogue or by news items are fetched by ID too, the same for everyone. Once you have added products, the app also fetches other records from the change file, in the file's order and whatever your products are, and keeps only those that match. Records include CISA's Vulnrichment enrichment.
• CISA Known Exploited Vulnerabilities catalogue (www.cisa.gov, or its GitHub mirror) and CISA advisories.
• EPSS daily scores for all CVEs, as one file (epss.empiricalsecurity.com).
• Public exploit and scanner-template indexes: the nuclei template index and Metasploit module metadata (raw.githubusercontent.com). The app reads index metadata only; it never downloads or runs exploit code.
• National and sector advisory feeds: NCSC New Zealand (www.ncsc.govt.nz), the Australian Signals Directorate's ACSC (www.cyber.gov.au), NCSC UK (www.ncsc.gov.uk), and CISA's ICS and general advisories (www.cisa.gov). The same feeds are fetched whatever sector or region you choose; the choice only changes the ranking on your phone.
• FirstSignal's own settings file: about once a day the app downloads one small signed file, https://firstsignalcyber.com/config/v1.json, which lets us pause a broken source or show a short notice. The request carries no identifier beyond the app's user-agent string. We log it without your IP address or location: we keep only the time, the result and the app version, for 3 days, and then they are deleted. Cloudflare serves the file and handles the connection under the Cloudflare Privacy Policy.
• Vendor security advisory feeds and security news RSS feeds, including the SANS Internet Storm Center feed (isc.sans.edu). The app stores the title, a short snippet and the link for each news item.
• End-of-support dates from endoflife.date (endoflife.date), as the whole list of products it covers (about 3 MB). The app downloads it at most once a week (and at most once a day after you add a product), only while a product you entered in Stack is one endoflife.date lists, and never while Stack is empty. The request names no product or version; the app keeps the dates for the products you entered and discards the rest.

2.2 Lookups that name one CVE

Some lookups ask about one specific CVE, so the request contains its ID. The service could, in principle, infer that someone at your IP address is interested in it.

• When you open a CVE, the app may look up its EPSS history (api.first.org), its public proof-of-concept index entry (nomi-sec PoC-in-GitHub, raw.githubusercontent.com), its CVE record if it is not cached (raw.githubusercontent.com) and its NVD record (services.nvd.nist.gov, with your key if you added one). These requests follow your action.
• One background lookup names a CVE. When a CVE your phone already holds, or one on your watchlist, appears in the CVE List change file, the app refetches that record by ID from raw.githubusercontent.com in the background. When your product list is empty nothing else is fetched with it, so the host sees your IP address and that CVE ID. This version asks no other service about the CVEs that match your stack unless you open them. If a later version adds such lookups, they will be off by default and this policy will be updated first.

The app sends no product names, vendor names or versions to any service.

2.3 Optional sources that use your own API key

These sources are off until you add your own key. Your use is governed by your own agreement with that service.

• NVD API (National Vulnerability Database, NIST). Your key is sent only to services.nvd.nist.gov, in a request header, never in a web address. If NVD redirects a request to another host, the key is not sent there.
• VulnCheck KEV (VulnCheck Inc.). Needs your own free VulnCheck Community key; without one the app sends VulnCheck nothing. Your key is sent only to api.vulncheck.com, in the Authorization request header, never in a web address, and it is not forwarded if VulnCheck redirects a request to another host. The app makes two requests, the same for every user: one asks VulnCheck for a download link to its KEV list (/v3/backup/vulncheck-kev), and one downloads that whole list from the short-lived signed address VulnCheck returns, on serve.vulncheck.com, which is sent no key. If VulnCheck answers that your account may not download that backup ("payment required" or "forbidden"), the app asks for the same list a page at a time from api.vulncheck.com (/v3/index/vulncheck-kev), with a page size and the cursor VulnCheck names for the next page; that copy is fetched at most twice a day, only during the daily large check. None of these requests names a CVE, a vendor, a product or anything about your stack: the list is matched on your phone. The app asks for the link on each background check and downloads the list again only when VulnCheck has published a new one; on a metered network the download waits for the daily large check. VulnCheck sees your IP address and your key, as any service you use with your own key does. Items it lists are labelled "VulnCheck KEV" with attribution to VulnCheck Known Exploited Vulnerabilities. Settings, API keys, Test key sends the link request once, and one small page request if the backup is refused. If VulnCheck answers "too many requests" the app waits and tries again later, and a key VulnCheck refuses on both routes shows as "Key not accepted". Removing the key stops all requests; the list already downloaded stays on your phone as cached public data until you use Delete all data.

Settings, API keys lists only these two keys. This version has no source that uses an abuse.ch or GitHub key and does not offer to save one. If a later version does, a key will go only to that service's own host, in a request header, and this policy will say what the requests contain.

2.4 On-device AI model

• On phones with a built-in on-device AI service, the model is provided and updated by the phone's operating system, not by FirstSignal.
• If your phone supports Gemini Nano but has not downloaded it yet, Settings, On-device model lets you ask Android to download it. Android and Google do the download; FirstSignal does not contact a model host.
• This version has no fallback model of its own: FirstSignal downloads no model file and does not fetch article pages from their publishers for summaries.
• Google's ML Kit library, which FirstSignal uses to reach Gemini Nano, queues diagnostic and usage reports to Google once it has started. On a test phone they named this app and its version, the ML Kit version and the phone's language, and carried a random identifier that ML Kit creates for this installation and keeps in the app's private storage, so removing the app removes it. The details sent with them were the country, the mobile network code, the phone model and maker, the Android version, the type of network and the time-zone offset. FirstSignal does not read or send these reports; Google does, under its own terms. The reports we looked at held no text you entered, no product from your stack and no text given to the model.
• ML Kit starts only on phones that have Google's AICore installed, the first time the app checks for Gemini Nano; on other phones it never starts and nothing is sent.

2.5 Your own feeds

If you add an RSS or Atom feed, the app fetches it directly from its publisher, at most once an hour on mobile data. The publisher sees your IP address and the time, as with any website you visit. These requests use a generic user-agent that does not name FirstSignal or its version, do not include your stack, settings or other feeds, and bypass any proxy set on the device so the address checks above always apply. A feed may redirect at most three times, only over HTTPS, and only to public addresses. The app stores the title, a short snippet and the link for each item, as for the built-in news feeds.

2.6 Send and Copy

• Send opens Android's share sheet with a short plain-text brief: the title, a one-line summary, CVE IDs, the lane, source names, links, and indicators in defanged form. It does not include your stack, product versions or organisation-specific reasons unless you turn on Settings, Privacy on this phone, Include why it matters to you when sending. Nothing is placed on the clipboard.
• Copy places the same text on the clipboard. On Android 13 and later it is marked as sensitive, so the system hides its preview.
• Send from Tools (Tools, Send) builds a fuller, ticket-ready summary that can include the proof for products you entered. It goes only where you send it, and copies of it are marked as sensitive.

The receiving app (for example a messaging or ticketing app) handles what you send under its own policies.

2.7 Send feedback

Send feedback (in Settings, under About) opens your own email app with a message to support@firstsignalcyber.com. Nothing is sent until you send it from your email app. By default the message includes a short diagnostic block: the app version, the Android version, your phone's manufacturer and model, the time of the last check and how many sources are working. The block is shown in full before you send, and you can switch it off. It never includes your stack, settings, feeds, alert rules or triage history. If you email us, section 7 applies.

2.8 Notifications and alert rules

Notifications are created on your phone by the app from data already on your phone; no notification service or server is involved. By default only Priority items push, as normal notifications that follow Do Not Disturb. Alert rules you create are stored on your phone and are never sent anywhere. A rule set to sound during Do Not Disturb only does so once you switch on Override Do Not Disturb for that rule in Android's notification settings; the app does not ask for Do Not Disturb access.

2.9 Optional anonymous usage counts ("Help improve FirstSignal")

This is off until you switch it on in Settings, Privacy on this phone, Help improve FirstSignal. It is never offered during setup. While it is off the app counts nothing and sends nothing. Debug and demo builds never count or send.

• What is counted. The Android version range, whether the phone is a phone, a foldable or a tablet, your language, whether it has 4 GB of memory or more; your role, sector and region (one value each, or "several"); how many days you opened the app, how many items arrived in each lane, how many you dismissed, saved or set aside, how often you used Send and Undo, which tools you opened, whether you imported a stack file, whether you used Explore search (never what you searched for), how many lead receipts were shown and shared, how many alerts were posted and opened, and how many alert rules, feeds, watchlist entries and products you have; how many checks ran and failed, which built-in sources failed, how long checks took, how much was downloaded and how much of that was on mobile data, which on-device text engine ran, why on-device text was not available if it was not, how many texts it wrote and how many of those failed their fact check; and whether Wi-Fi only, notifications and quiet hours are on. Numbers are sent as ranges (for example 1-5 or 21-100), never exact.
• What is never sent. CVE IDs, product, vendor or feed names, your stack, watchlist or search text, notes, API keys, anything you type, an account, or an advertising or device ID. A feed you added is never named, even if it fails.
• How it is sent. Each kind of count is its own small report, built early in the week from the week before and sent on a different day of the week, with a random code that is used once and links nothing. The app shows the exact text of every waiting report in Settings, Help improve FirstSignal, See what is sent. Reports go over HTTPS to usage.firstsignalcyber.com, whose certificate authorities the app checks. The app sends nothing while a proxy is set, follows "Sync on Wi-Fi only", and drops a report that fails to send instead of retrying. The only header the app sets is Content-Type; the network library adds the usual ones, with a User-Agent that names the library, not this app.
• What we keep. The collector adds each report to weekly totals and keeps no individual report, no arrival time and no IP address. Totals are deleted 90 days after the week they describe. Our database provider keeps point-in-time recovery copies (Cloudflare D1 Time Travel) for up to 30 days, so a deleted total can remain in those copies for up to 30 more days. The random codes are deleted after at most 15 days, and recovery copies can hold a deleted code for up to 30 more days; a code carries only the week it arrived in, never a total, a time or an address. Because a report carries no ID and is only counted into a total, a report that has already been sent cannot be picked out and removed. Turning the switch off deletes the counts and queued reports on your phone at once.
• Who handles it. The collector runs on Cloudflare (United States), which acts for us as a processor. Cloudflare sees your IP address while a report is delivered, for delivery and abuse prevention, and does not give it to us. Cloudflare, the hosting provider, briefly records the IP address of requests it blocks for sending too many reports. The transfer outside New Zealand is covered by Cloudflare's data processing terms: under the New Zealand Privacy Act 2020 (information privacy principle 12) we send information overseas only to a provider that handles it for us, and for users in the EU and UK those terms include the standard contractual clauses. The switch is your consent; you can withdraw it at any time.
• Age. The app is for adults and is not directed at children.

2.10 This website

Like most websites, firstsignalcyber.com keeps short-lived security logs of visits (such as IP address, browser and the page requested), which are deleted after 3 days. The website uses no cookies, no analytics and no advertising.

3. Purchases (Google Play Billing)

FirstSignal Pro is sold through Google Play. Google processes the payment and holds your payment details and purchase records under the Google Privacy Policy and the Google Play Terms of Service. The app receives only the purchase status and a purchase token from Google Play on your device, to unlock Pro features. It does not send that information to us. We do not see your name, email address or payment details.

Google's Play Billing library, which FirstSignal uses for purchases, sends Google a short report about the phone when it starts. On a test phone the report carried the country, the mobile network codes, the phone's make and model, its build fingerprint, the Android version, the network type and the time zone offset. It goes to Google, not to us, and it holds no purchase token and nothing about the products you entered. The library starts only when the app needs to know what you have bought: when you open Pro or Founding supporter, when you restore a purchase, when you use something that needs Pro and the phone does not already know you have it, and, if you have bought Pro or Founding supporter, each time you open the app, to check that the purchase still stands. On a phone that has bought nothing and does none of these, the library never starts and nothing is sent.

Google may give us aggregated, non-identifying sales and app statistics in the Play Console, as it does for every Play developer. If you contact us about a purchase, Google Play may show us the order number you give us.

4. What we do not do

• No accounts or sign-in.
• No analytics, telemetry or crash-reporting library of our own, apart from the optional anonymous usage counts you can switch on (section 2.9). Google's ML Kit library sends diagnostic and usage information to Google (section 2.4), and Google's Play Billing library sends a short device report to Google when it starts (section 3). Android and Google Play may also collect crash and performance data under your device settings and Google's policies; that data is Google's, not ours, and it does not include the products you entered.
• No advertising, advertising IDs or tracking.
• No sale or sharing of personal information. We have none to share.
• No location, contacts, camera, microphone or SMS access, and no access to your other files. The app opens a file only when you choose it in Android's file picker (a product list to import, or a backup file to restore) and writes one only where you choose to save a backup.

5. Permissions the app declares

This list matches the release build's merged manifest.

• Internet and network state: to download public data, and to wait for a connection (and for Wi-Fi for the large daily files) before checking.
• Notifications (Android 13 and later): to post alerts and the daily briefing. Asked for during setup, after the explanation, never at first launch.
• Run at startup and keep awake (added by Android's WorkManager library): so scheduled background checks resume after a restart and can finish once started.
• Google Play billing: to show and process Pro purchases through Google Play.
• On-device AI service (Android's AICore): to use the phone's built-in on-device model for summaries. The text given to the model is processed on the phone; see section 2.4 for what Google's ML Kit library sends to Google.
• An app-internal permission that stops other apps from sending events to the app's own receivers.

The app does not ask for Do Not Disturb access, an exemption from battery optimisation, exact alarms or a foreground service. To have a rule sound during Do Not Disturb, switch that on for the rule in Android's settings. To make checks run more reliably, change FirstSignal's battery setting in Android yourself.

6. Children

FirstSignal is a security news and alerts app for adults and is not directed at children. We do not collect personal information from anyone, including children; section 2.4 describes what Google's ML Kit library sends to Google.

7. Your rights (New Zealand Privacy Act 2020 and similar laws)

Under the New Zealand Privacy Act 2020 you have the right to ask for access to, and correction of, personal information an agency holds about you. Because FirstSignal does not send your information to us, we normally hold no personal information about you. The optional usage counts are kept only as weekly totals with no ID, so we cannot find or remove one phone's contribution (section 2.9). We delete those totals 90 days after the week they describe. If you email us, we hold your email and message only to reply, and delete them within 12 months of the last message unless they are needed to resolve an open issue.

You can contact us at support@firstsignalcyber.com with any privacy question or request. If you are not satisfied with our response, you can complain to the Office of the Privacy Commissioner (New Zealand) at https://www.privacy.org.nz. If you live elsewhere, you may have similar rights under your local law, and you can contact your local data protection authority.

Legal basis. In New Zealand we follow the information privacy principles of the Privacy Act 2020: we collect only what is needed for a stated purpose (the optional usage counts, and the emails you send us), from you, openly, and we keep it only as long as this policy says. For people in the EU or the UK, where the GDPR or the UK GDPR applies, we rely on your consent for the optional usage counts (you can withdraw it at any time by switching the setting off), and on our legitimate interest in replying to you for the emails you send us.

8. Security

Data on your phone is protected by Android's app sandbox and, for API keys, encryption with an Android Keystore key. All network requests use HTTPS: the app's network security configuration forbids plain HTTP and trusts only the system's certificate authorities, not ones added by users or other apps. We recommend using a screen lock on your phone. No method of storage is perfectly secure; please report security issues to security@firstsignalcyber.com.

9. Changes to this policy

If this policy changes, we will update the "Last updated" date and publish the new version at https://firstsignalcyber.com/privacy. Material changes, such as a new data flow, will also be noted in the app's release notes before they take effect.

10. Contact

FirstSignal
support@firstsignalcyber.com
New Zealand