Trust
Security and responsible disclosure
We ask customers to trust us with evidence of their worst days — leaked credentials, unknown exposed systems, live phishing infrastructure. This page sets out how that material is protected, how we build, and how to tell us when we have got something wrong.
- Last updated
- 9 September 2026
- Status
- Practices under review
Template — not legal advice
This security page is an unreviewed draft template. No lawyer has looked at it.
It was written as a starting point for the 0DaySecure team, not as a binding document. It has to be reviewed by qualified counsel in the relevant jurisdictions and rewritten to match what the company actually does before the site goes live. Every bracketed placeholder needs a real value, and every statement of practice needs to be checked against reality.
The practices described here have not yet been verified line by line against the shipped platform, and the safe-harbour wording in the disclosure section has legal effect. Both need review before this page is published.
Do not rely on this document. Do not publish it as-is.
Platform security
How we protect customer data
Practices, described plainly. Where a control is available rather than on by default, we say which.
Encrypted in transit and at rest
TLS on every connection to the platform and between our own services. Data at rest is encrypted at the storage layer, with keys held in a managed key service rather than in application config.
Least privilege, by role
Access is granted by role, not by person, and reviewed when a role changes. Nobody holds standing production access by default; elevated access is requested, time-bound and recorded.
Tenant isolation
Findings belong to one tenant and are queried through a tenant boundary enforced in the data layer, not only in the interface. Intelligence is never pooled in a form that exposes one customer to another.
Audit logging you can read
Sign-ins, permission changes, scope changes, credential reveals and exports are written to an audit trail your own administrators can inspect and export — not just ours.
SSO and SAML available
Single sign-on with SAML 2.0 is available so account lifecycle stays in your identity provider. Where SSO is not used, multi-factor authentication is available on local accounts.
Hardened, boring infrastructure
Managed cloud infrastructure, private networking between services, no shared administrative credentials, and secrets held in a secrets manager with rotation.
Backups are encrypted and restore-tested. Production access is logged. If a security incident affects your data, we will tell you — what happened, what we know, what we do not yet know, and what we are doing about it — without waiting until the story is tidy.
Sensitive material
How we handle intelligence material
Some of what we collect on your behalf is dangerous to hold. Leaked passwords, phishing kits, malware samples and personal data belonging to your staff and customers all pass through the platform.
Credential material is segregated
Passwords and hashes live in a restricted store, separate from the finding metadata that points at them, with their own access controls.
Masked by default, reveal is deliberate
An analyst sees the shape of a password — length, character classes, whether it matches a corporate pattern — without seeing the value. Revealing it is a separate, permissioned action, and it is logged.
We never test what we find
Found credentials are never used to authenticate to anything, on your estate or anyone else’s. Validation by login attempt is not part of this product.
Nothing sensitive travels in a notification
Alert emails, chat messages and webhooks carry a link to the finding. The credential itself stays inside the platform, behind authentication.
What an analyst actually sees
Credential pair exposed in combolist
Dark web monitoring · illustrative example
- Account
- finance-ops@example.com
- Password
- ••••••••••10 chars · Aa1
- Source
- combolist · first seen 2026‑08‑14
- Storage
- restricted store · encrypted at rest
Revealing the plaintext value needs the credential:reveal permission, and writes an entry to your tenant audit trail naming the user, the finding and the time.
Illustration of the interface, drawn in markup. The account, source and dates are invented for this page.
Engineering
How we build the thing
A security product built carelessly is worse than no product, because it concentrates risk. These are the habits we hold ourselves to.
Every change is reviewed
Nothing reaches production without a second pair of eyes and a green pipeline. Branch protection is enforced, not encouraged.
Automated checks in the pipeline
Dependency and container scanning, static analysis and secret scanning run on every pull request, with known-vulnerable dependencies blocking a merge.
No production data in development
Engineers build against synthetic fixtures. Real intelligence material does not get copied into a laptop, a test environment or a support ticket.
We practise the incident
A written incident response process with named roles, a severity scale and a rehearsal schedule — so the first time we use it is not during a real incident.
We also run our own product against our own estate. Every domain we own is in scope for our attack surface module, our own credentials are monitored, and our own lookalike domains get taken down. If a finding is not good enough to act on internally, it is not good enough to ship.
Compliance
Where we actually are on certifications
0DaySecure does not currently hold SOC 2, ISO/IEC 27001, or any other audited compliance certification. The product is still in development. We are not going to put a badge on this page that an auditor has not issued, and we are not going to describe an intention as an achievement.
What we can offer today is the detail: the practices above, an architecture walkthrough with the engineers who built it, a completed security questionnaire, and a data processing agreement to put in front of your own counsel. If a certification is a hard procurement gate for you, tell us early and we will be honest about the timeline rather than optimistic about it.
This section will be rewritten — with the report, the scope and the audit period named — when there is something real to name.
Responsible disclosure
Found something? Tell us.
We would rather hear about a flaw from you than read about it later. Reports are welcome from anyone — you do not need to be a customer, and there is no form to fill in.
What is in scope
- The 0DaySecure application and API, on any hostname under 0daysecure.com.
- This marketing website.
- Our public infrastructure — DNS, mail configuration, TLS configuration.
- Anything that lets one tenant see, infer or affect another tenant’s data. This is the category we care most about.
What is out of scope
- Findings from an automated scanner submitted without a working proof of concept or an explanation of impact.
- Missing hardening headers, cookie flags, or TLS cipher preferences with no demonstrated exploit path.
- Rate limiting on unauthenticated endpoints, unless you can show real harm.
- Social engineering of our staff, contractors or customers; physical attacks; anything targeting a third-party service we merely use.
- Self-inflicted issues that require a victim to paste code into a console or install a malicious extension.
- Reports that a leaked credential we surfaced is real. That is the product working.
What we ask you to do
- Email security@0daysecure.com with enough detail for us to reproduce it: the endpoint, the request, the result, and why it matters. Screenshots and a short recording help.
- Use a test account of your own where you can, and tell us which account you used.
- Stop at proof. Once you have shown the flaw exists, do not go further into the system.
- Give us a reasonable window to fix it before you publish. We suggest 90 days, and we are happy to agree something different in writing if the issue warrants it.
What we ask you not to do
- Do not access, modify, download or delete data belonging to anyone else. If you stumble into another tenant’s data, stop, tell us immediately, and delete anything you retrieved.
- Do not run denial-of-service tests, load tests, or brute-force and credential-stuffing attacks against us.
- Do not use a flaw to persist, install anything, or maintain access.
- Do not extort. A report conditioned on payment is not a disclosure, and we will treat it as what it is.
- Do not publish details, including on a conference slide, before the agreed date.
What we commit to
- Acknowledgement within 3 business days — by a human, not an autoresponder.
- An initial assessment within 10 business days telling you whether we have reproduced it, how we have rated it, and roughly when we expect to fix it.
- Progress updates at least every 14 days until it is closed.
- Credit if you want it. We will name you when we publish the fix, or keep you anonymous — your choice.
- No legal threats for good-faith research. See below.
We do not currently run a paid bug bounty. If that changes we will say so here rather than leaving you to guess.
Safe harbour
If you make a good-faith effort to comply with this policy while researching a vulnerability in our systems, we will treat your research as authorised. We will not initiate or support legal action against you in connection with it, and if a third party brings action against you for research that followed this policy, we will make it known that your activity was authorised.
Good faith means: you stayed in scope, you stopped at proof, you did not access or retain other people’s data, you did not degrade the service, and you reported promptly and privately. If you are unsure whether something is in bounds, ask us first at security@0daysecure.com — we would much rather have that conversation before the testing than after it.
This safe harbour is a commitment from us. It cannot waive the rights of third parties, and it does not authorise you to breach the law. Nothing in it applies to activity outside the scope above.
Send the report here
One inbox, monitored by the engineers who can fix it.
security@0daysecure.comAsk us for a PGP key if you need to send the report encrypted.
Response targets
- 3 business days
- Human acknowledgement
- 10 business days
- Reproduction and severity assessment
- 90 days
- Suggested disclosure window, negotiable
Not a security issue?
Product problems and account questions go to support@0daysecure.com. Privacy requests are handled under our privacy policy.
Bring your security review to us.
Send the questionnaire, the DPA, or the awkward architecture question. We would rather answer it before you buy than after.
- Architecture walkthrough with engineers
- Security questionnaires answered
- Disclosure reports always welcome