Security Policy

Effective date: June 21, 2026 · Version 1.0

Security is the purpose of AuthForge, not a feature of it. This Security Policy describes the security program operated by EactiveNet, Inc., the shared-responsibility model that applies because AuthForge is self-hosted, and the responsible-disclosure process by which security researchers can report vulnerabilities to us. It complements our machine-readable disclosure policy published at /.well-known/security.txt.

1. Shared-responsibility model

Because AuthForge runs on infrastructure you control, security is a shared responsibility. We are responsible for the security of the Software we publish, our website, and our corporate systems. You are responsible for the secure operation of your Self-Hosted Deployment, including the protection of cryptographic key material, the configuration of password and session policies, network and host hardening, patching, backups, and the lawful handling of the credentials and session data your deployment processes. We provide secure defaults and documentation to help you meet that responsibility.

2. Cryptography and data protection

AuthForge is built on modern, peer-reviewed cryptographic primitives: passwords are hashed with Argon2id using memory-hard parameters and an optional server-held secret; sessions are signed with Ed25519 (EdDSA) and validated against a published JSON Web Key Set; refresh tokens are high-entropy random secrets stored only as digests and compared in constant time; and secret material is wiped from memory after use. Because the software is self-hosted, identities and credentials never leave your environment, which materially reduces the data-exposure surface compared with cloud-hosted identity providers.

3. Our corporate security program

We operate our own systems on the principles of least privilege, defense in depth, and separation of duties. Access to production and corporate systems is restricted to authorized personnel, granted on a need-to-know basis, protected by strong authentication, and reviewed periodically. Data is encrypted in transit, and we maintain logging and monitoring designed to detect and respond to anomalous activity.

4. Secure development and testing

Security is verified, not merely asserted. The cryptographic core is covered by an automated test suite that includes adversarial cases — rejection of forged, tampered, expired, and algorithm-confused tokens, credential-enumeration resistance, and brute-force lockout. Every change runs through continuous integration that enforces static analysis with warnings treated as errors and a supply-chain gate that screens dependencies for known advisories, disallowed licenses, and untrusted sources. The source is open and available for independent inspection.

5. Responsible disclosure policy

We welcome reports from security researchers and are committed to working with the community to verify and remediate vulnerabilities. If you believe you have found a security issue in AuthForge or our website, please report it privately to security@authforge.dev. Where possible, encrypt sensitive details and include a clear description, the affected component and version, reproduction steps, and any proof-of-concept. We will acknowledge your report within three (3) business days, keep you informed of our progress, and aim to coordinate a remediation and public disclosure within ninety (90) days. We are grateful to acknowledge researchers who help keep AuthForge secure.

6. Scope and guidelines

In conducting security research, please: only test against systems you own or are expressly authorized to test, such as your own deployment, and never against another customer’s environment; avoid privacy violations, data destruction, service degradation, and any interruption to others; do not access, modify, or exfiltrate data that is not yours; and give us a reasonable opportunity to remediate before any public disclosure. The following are generally out of scope: findings from automated scanners without a demonstrated impact, social-engineering or physical attacks, denial-of-service testing, and reports about missing best-practice headers without a concrete vulnerability.

7. Safe harbor

We consider security research and vulnerability disclosure conducted in good faith and in accordance with this Policy to be authorized conduct. We will not pursue or support legal action against, and will work to protect from liability, researchers who comply with this Policy. If legal action is initiated by a third party against you for activities that were conducted in accordance with this Policy, we will make this authorization known. This safe harbor does not apply to conduct that is unlawful or that intentionally harms us, our customers, or others.

8. Incident response

We maintain an incident-response process to identify, contain, investigate, and remediate security incidents affecting our systems, and to notify affected parties and authorities where required by law. Because we do not host your deployment, you are responsible for incident response within your own environment; we will provide reasonable assistance and timely information about vulnerabilities in the Software to help you respond.

9. Compliance posture

AuthForge is architected to support the control objectives commonly required by frameworks such as SOC 2, ISO/IEC 27001, HIPAA, and the GDPR — including strong cryptography, access control, auditability, and data residency. Self-hosting places those controls, and the data they protect, within your own environment and audit boundary. Statements about framework alignment describe architectural fit and are not, by themselves, a representation that the Company or the Software holds a particular certification; current attestations, where available, are provided on request under appropriate confidentiality terms.

10. How to contact us

Report vulnerabilities to security@authforge.dev and see /.well-known/security.txt. For acceptable-use or abuse matters, contact abuse@authforge.dev.