Security claims should be specific and verifiable.
This page describes security mechanisms represented in the Cybatar application. It deliberately avoids claims of certifications, guarantees or controls that are not publicly evidenced.
Cybatar is a security platform, not a compliance certificate. Use of the platform does not by itself make an organisation compliant with a law, framework or standard, and it does not guarantee prevention of cyber incidents.
Security mechanisms represented in Cybatar.
Tenant-scoped data access
Core Cybatar controllers use tenant-resolution logic so operational records are queried and authorised within the active Cybatar tenant context.
Two-factor authentication support
The application contains TOTP-based two-factor authentication support for users with a configured second-factor secret.
Security headers
Authenticated Cybatar routes use a dedicated security-headers middleware layer.
Protected ingestion credentials
SIEM receivers use bearer-token verification, while Web Shield and webhook workflows can use signed request verification. Shared secrets are designed to be protected at rest.
Audit records
Cybatar contains audit-event and activity-log structures used by governance, evidence and administrative workflows.
Evidence handling
Digital-forensics and assurance workflows include evidence records, hashes, chain-of-custody events and evidence review structures.
Report a security concern.
Security researchers and users can use the public contact channel to report a potential vulnerability or security concern. A machine-readable security contact is also published at /.well-known/security.txt.
What we do not claim here
Need to understand a specific control?
Use the contact channel for deployment-specific assurance questions or review the public security knowledge base.