Security

How to report a vulnerability, and what happens next.

Last updated: July 2026

Reporting a vulnerability

If you believe you have found a security vulnerability in IdentitySuite or on this website, please report it privately. Do not open a public issue and do not disclose it publicly until a fix is available.

Email security@identitysuite.net. That mailbox is read before anything else.

If you would rather not use email, the contact form has a “Security vulnerability” request type that reaches the same place — but email is the better channel, because you can attach a proof of concept.

A useful report usually contains:

  • the affected component and version (NuGet package and version number, or the URL on this site);
  • whether you are reporting against your own installation or against this website;
  • a description of the issue and why you believe it is a security problem;
  • the steps to reproduce it, or a minimal proof of concept;
  • the impact you think it has, and any conditions required to exploit it;
  • how you would like to be credited, or whether you prefer to stay anonymous.

What you can expect

  • Acknowledgement within 3 working days. A human reply, not an autoresponder.
  • An initial assessment within 10 working days, telling you whether the issue is confirmed, what severity it has been assigned, and what the intended fix timeline is.
  • Progress updates until the issue is resolved, and notice before any public disclosure.
  • Public credit in the release notes for the version that contains the fix, unless you ask to remain anonymous.

IdentitySuite does not currently run a paid bug bounty programme. Reports are handled seriously and credited, but there is no monetary reward — that is stated here rather than left ambiguous.

Coordinated disclosure

The goal is to fix the issue and get the fix into the hands of everyone running IdentitySuite before details become public. The working timeline is 90 days from the confirmation of a report, shortened when a fix ships earlier and extended only if a fix genuinely requires more time — in which case you will be told why.

Because IdentitySuite is self-hosted, publishing a vulnerability affects every installation that has not yet updated. Please give installations a chance to update.

Scope

In scope:

  • the IdentitySuite NuGet packages and the administration UI they ship;
  • the license activation and validation endpoints;
  • this website, identitysuite.net, including the purchase flow.

Out of scope:

  • installations operated by third parties — if you found an issue in someone else's deployment, report it to them, not here, and do not test against systems you are not authorised to test;
  • vulnerabilities in upstream dependencies (OpenIddict, ASP.NET Core, database providers) — report those to their maintainers; if IdentitySuite's use of them makes the impact worse, that part is in scope;
  • automated scanner output with no demonstrated impact, missing hardening headers with no exploit path, and reports about email configuration (SPF/DMARC) of third-party senders;
  • denial of service through traffic volume, and social engineering of the maintainer.

Security updates

Fixes are published as new versions of the affected NuGet packages and listed in the changelog in the documentation. Security-relevant releases are called out explicitly, so that you can tell them apart from feature updates when deciding how urgently to upgrade.

Keeping your installation current is part of the security model: IdentitySuite runs on your infrastructure, so applying updates is your side of the arrangement.

How IdentitySuite is built

  • Protocol handling is delegated to OpenIddict, certified by the OpenID Foundation, rather than reimplemented — no custom OAuth 2.0 or OpenID Connect logic to get wrong.
  • User and credential management is delegated to ASP.NET Core Identity, including password hashing and two-factor authentication.
  • Passkeys (WebAuthn/FIDO2) are supported as a phishing-resistant alternative to passwords.
  • Everything is self-hosted: identity data stays inside your infrastructure, and no credentials transit through servers operated by IdentitySuite.