Security

1. Scope

This page describes controls that are present in the current MonoDuty application and production configuration. It is not a certification, penetration-test report, warranty, or promise that a security incident cannot occur.

Specific contractual or regulatory controls apply only when they are documented in an applicable customer agreement.

2. Production Topology

The current production service runs on a single European virtual server behind Cloudflare and Nginx. The database and Redis are restricted to local service access, and public application traffic uses named TLS virtual hosts.

Worker names and queue labels are logical routing identifiers in the current single-host deployment. MonoDuty does not represent them as physically independent locations, and the current public service does not promise geographic failover, load-balanced application replicas, or provider redundancy.

3. Data Protection

• Public endpoints accept TLS 1.2 and TLS 1.3.
• Passwords and selected credentials are stored using one-way hashing where the application does not need the original value.
• Webhook metadata is bounded and known credential fields are redacted.
• Token-bearing Webhook and Heartbeat paths are excluded from ordinary Nginx access and error logs.
• Production secrets are held outside release directories with restricted file permissions.

The current application does not claim application-level encryption for all database fields or backup archives. Customers should treat issued URLs and access tokens as credentials.

4. Access Control

MonoDuty uses server-side browser sessions, scoped API tokens, workspace roles, team membership, authorization policies, ownership validation, request validation, CSRF protection, and rate limits. Password resets, email verification, and cross-origin sign-in handoffs use time-limited or single-use flows.

Users can enable time-based one-time-password multi-factor authentication, receive single-use recovery codes, review active browser sessions, revoke other devices, and re-verify with a password, authenticator code, or recovery code before sensitive actions. Enrollment secrets and newly generated recovery codes are displayed only during the active setup flow and are not placed in browser storage. The browser session credential is held in a Secure, HttpOnly, host-only API cookie rather than local storage. The current catalogue does not include enterprise federated sign-in.

5. Operational Monitoring

The deployment includes application and system logs, health endpoints, scheduler and queue supervision, and error and service-state records used for diagnosis. Credential-bearing ingress routes deliberately omit ordinary request logging.

MonoDuty does not claim a continuously staffed security operations center, a dedicated SIEM, tamper-proof logs, or complete logging of every user and system action.

6. Assurance Status

MonoDuty is an Estonian company and has designed the Service with EU data-protection principles in mind. The public legal pages describe current practices; they are not evidence of a completed independent compliance examination.

MonoDuty does not currently publish an ISO, SOC, payment-card, health-data, or similar security certification. No badge or certification should be inferred unless a current report is supplied in writing.

7. Security Incidents

Operational response may include validating an alert, limiting access, containing affected services, preserving relevant evidence, restoring service, and documenting follow-up work. Notification to customers, regulators, or individuals follows applicable law and the applicable written agreement.

This public page does not promise a dedicated response team, a round-the-clock response time, or a fixed notification deadline shorter than the law requires.

8. Vulnerability Management

Release gates include dependency-advisory checks, automated application tests, code formatting and static checks, and production health verification. Operating-system and application updates are applied through controlled deployment procedures.

No public remediation deadline or continuous third-party scanning commitment is made here. Material customer-specific requirements must be agreed in writing.

9. Backup and Recovery

The current deployment creates access-restricted local backups of the MySQL database and shared application storage, records SHA-256 integrity checksums, retains completed archives for 14 days, and has a tested restore procedure.

Backups are compressed but are not represented as application-encrypted, off-site, geographically replicated, or an automatic failover system. The current single-host topology remains a continuity limitation.

10. Provider Risk

MonoDuty depends on infrastructure, edge, email, telecommunications, and identity/abuse-prevention providers. Provider failures or policy changes can affect availability and delivery.

Providers are limited to the access needed for their role where the integration allows it. A customer with formal vendor-risk requirements should request the current provider and contract details before relying on the Service.

11. Security Reports

Report a suspected vulnerability privately to [email protected] with the affected endpoint, reproducible steps, impact, and a safe proof of concept. Do not access another customer’s data, disrupt the Service, use social engineering, or publish exploitable details before MonoDuty has had a reasonable opportunity to investigate.

No monetary reward or formal safe-harbor program is promised by this page.

12. Contact

Security and trust questions can be sent to [email protected] or through the contact form.