Found a security problem? Tell us, and here is what happens next.
How to report a vulnerability in the SecureEyes app, the Hub, our servers or this website, what to expect from us, and the rules for good-faith research. There is no bug bounty; there is a person who reads every report.
What this policy covers
This policy covers software SecureEyes makes and services SecureEyes runs. It applies to the versions currently supported: the current App Store release of the app, the Hub release on the update feed, and the services as they run today. If you found a problem in an older version, check it against the current one first; if it is still there, report it.
- The SecureEyes app for iPhone, iPad and Mac, as published on the App Store.
- SecureEyes Hub: the sehub daemon, its elevated helper, its admin web page, and the hub installer at get.secureeyes.app.
- The relay at relay.secureeyes.app and the licence server at license.secureeyes.app.
- This website, secureeyes.app, and the Hub update feed at updates.secureeyes.app.
How to report
Email is the one channel, and it reaches a person, not a queue. Do not report a vulnerability through App Store reviews, social media or a public issue, where an attacker reads it before we do.
- 01Write to security@secureeyes.app. A plain email is fine. If you would rather encrypt, say so in a first message and we will arrange a key with you; we do not publish a PGP key yet, and encryption is never required.
- 02Say which product and which version: the app's version and build (Settings, About), the Hub's version (its admin page, or system/health), or the service and the time you saw the problem.
- 03Describe what you did and what you saw, step by step, so we can reproduce it. A proof of concept, a request and response, or a screenshot helps. Redact any camera password or footage before sending.
- 04Say what you think an attacker could do with it, and whether you have any sign that it is already being exploited. That one line changes how fast we move.
- 05Tell us how to reach you, and whether you want to be credited by name when the fix is published.
There is no bug bounty. We do not pay for reports, and we will say so rather than let you expect otherwise. We do fix what you find, tell you when it is fixed, and credit you if you want it.
What to expect from us
- 01An acknowledgement within 3 business days of your email, from a person, with a reference you can quote.
- 02A first assessment within 10 business days: whether we could reproduce it, how severe we think it is, and what we plan to do.
- 03Updates as the fix progresses, and a message when it has shipped. If we need longer than planned, we say so before the date passes, not after.
- 04Disclosure coordinated with you. The default window is 90 days from your report. We publish earlier when the fix has shipped and users have had time to update, and we may ask for longer when a fix needs a release cycle on the App Store or the Hub feed; we will not go past 90 days without telling you why.
- 05Credit, if you want it, in the published note about the fix. If you prefer not to be named, we will not name you.
Reports to this address are read and handled by SecureEyes. We may share the technical content of a report with a party whose code or service is involved, for example a camera vendor, to get it fixed; we do not share your identity without asking you.
Safe harbour for good-faith research
We want to hear from people who look. If you research SecureEyes in good faith, follow the rules in the next section, and report what you find to us, we will not take legal action against you for that research, and we will not refer it to law enforcement. If a third party, such as a camera vendor or a hosting provider, starts a legal action against you for research that followed these rules, we will say publicly that your research was authorised under this policy.
Good faith means you tried to avoid harm, you took no more than was needed to show the problem, you kept what you found confidential until the disclosure we agreed, and you did not use it for anything else. This policy is not a licence to break any law, and we cannot authorise access to systems that are not ours.
The rules
Research that follows these rules is covered by the safe harbour above. Research that does not is not.
- Test only against devices, cameras, Hubs and accounts you own or have explicit permission to use, and against the public website. A relay or licence server test must use your own Hub and your own licence.
- Never access, view, record or keep another person's camera, footage, snapshot, event or credentials. If a flaw would let you, stop at proving that it would and report it. Do not demonstrate it on anyone else's camera.
- No denial of service. Do not flood the relay, the licence server, the update feed or the website, and do not test how much load they take.
- No social engineering of SecureEyes, of its hosting providers or of other users. No phishing, no pretext calls, no physical access attempts.
- The moment you reach personal data that is not yours, including footage, stop, keep no copy, and report. Say in the report what you saw and that you deleted it.
- Do not change, delete or plant anything on a system you do not own. A proof of concept reads; it does not write.
- Keep what you found to yourself and us until the disclosure date we agree. Do not sell it, publish it early, or hand it to a third party, and do not use it to demand anything.
Out of scope
We cannot fix these, and a report about them goes to the party that can. Where we know who that is, we will tell you.
- Camera firmware and camera vendors' own apps and clouds. SecureEyes talks to cameras over ONVIF, RTSP and the vendors' HTTP interfaces; a flaw in the camera's own software is the vendor's to fix. Report it to them; many have a security page of their own.
- The App Store, StoreKit, iCloud, iCloud Keychain and other Apple systems. Report those to Apple.
- Amazon Web Services and the other hosting and network providers under our servers. Report those to the provider.
- Reports that only quote a scanner's output, a missing security header on a static page, or a software version number without a way to exploit it.
- A camera or network that is misconfigured by its owner, such as a camera with its default password, which SecureEyes can warn about but cannot change.
If you are not sure whether something is in scope, send it anyway. We would rather read a report that turns out to be someone else's than miss one that is ours.
The EU Cyber Resilience Act
SecureEyes, the app and the Hub, is a product with digital elements sold in the European Union, and the Cyber Resilience Act (Regulation (EU) 2024/2847) applies to it. This is a statement of what we do under the Act, not legal advice.
When we become aware of a vulnerability in SecureEyes that is being actively exploited, or of a severe incident that affects the security of SecureEyes, we report it through ENISA's single reporting platform, to the authorities the Act names, on the Act's timeline: an early warning within 24 hours of becoming aware, a notification within 72 hours with what is then known about the vulnerability and the measures taken, and a final report within 14 days of a fix or mitigation being available (within one month of the notification for a severe incident).
We inform affected users without undue delay: on this website, in the app's release notes on the App Store, and in the Hub's release notes on the download page, with what the problem was, which versions it affects, and what to do. SecureEyes keeps no user accounts and no email list, so there is no message we can send to you directly; this page and the release notes are where the word goes out.
Support period
Security fixes are provided for the SecureEyes app and the SecureEyes Hub for five years from the date of each release. A fix ships as a new version: an app update on the App Store, and a Hub update on the signed feed, which the Hub and the app offer when it is published. Within the support period, the way to receive security fixes is to keep the app and the Hub updated; a version older than the current one is not patched in place.
The relay, the licence server and this website are services rather than shipped software, and are maintained for as long as they run.
Changes to this policy
This policy is dated 22 October 2026. A change to what we promise, to the address, or to the scope will appear here with a new date. The machine-readable contact file at secureeyes.app/.well-known/security.txt names this page as its policy and carries its own expiry date, which we renew each year.
Contact
Security reports go to security@secureeyes.app. Anything else about SecureEyes goes to support@secureeyes.app.