Zayloft
Zayloft
Least privilege
Users and applications should receive only the permissions required for their responsibilities.
Zayloft security
Security should be part of the platform architecture, the integration model and the daily operating process—not an afterthought added around production systems.
Zayloft is designed around controlled access, scoped credentials, tenant boundaries, secure transport, event verification, auditability and practical operational safeguards across communications and identity workflows.
Security starts with explicit boundaries.
A secure communications platform should make it clear who can access what, which application is acting, where secrets are stored, how events are trusted and how important changes are recorded.
Tenant isolation
Organization and project data should remain separated across resource access and processing.
Defense in depth
Security should combine identity controls, transport protection, application safeguards and operational review.
Traceability
Important authentication, credential, configuration and administrative events should be attributable.
Identity and access controls for people and applications.
Human access and machine access have different risks. Zayloft’s architecture separates user authentication from application credentials and supports controlled access patterns for both.
Role-based access
Assign permissions according to responsibilities such as engineering, operations, finance, support and administration.
Strong authentication
Use appropriate multifactor and modern authentication controls for sensitive account access.
SSO & federation
Enterprise identity patterns can use standards such as SAML 2.0 and OpenID Connect where configured.
Service credentials
Applications should use scoped machine credentials rather than shared human credentials.
Credential rotation
Rotate exposed, outdated or high-risk credentials and remove access that is no longer needed.
Provisioning lifecycle
Use structured onboarding, role changes and deprovisioning so access follows the current organization state.
Secrets belong on trusted server-side systems.
API keys, SMPP credentials, webhook signing secrets and other sensitive values should never be embedded in public code or distributed where they cannot be protected.
Protected storage
Store secrets in protected server configuration or appropriate secret-management systems.
Environment separation
Keep development, testing and production credentials independent.
Scoped access
Issue credentials only for the projects, environments and capabilities an application requires.
Revocation
Remove or rotate credentials quickly when access changes or compromise is suspected.
Protect data while it moves between systems.
Public APIs and supported persistent protocol connections should use modern secure transport. Applications should also validate the systems they connect to instead of disabling certificate or signature checks.
HTTPS & TLS
Use modern TLS for API and browser transport.
Secure persistent connections
Use secure connection options for supported persistent protocols where available and appropriate.
Webhook signatures
Validate signed webhook payloads before trusting event data.
Replay resistance
Use event identifiers, timestamps and idempotent processing to reduce replay and duplicate-processing risk.
Application security should fail safely.
Distributed systems encounter invalid requests, unexpected inputs, retries and partial failures. Secure integrations should treat these as normal conditions and handle them explicitly.
Input validation
Validate structured requests, resource identifiers, formats and allowed values before processing.
Safe error handling
Return useful machine-readable errors without exposing provider secrets, internal credentials or unnecessary infrastructure details.
Idempotency
Use idempotent request patterns so retries do not silently duplicate sensitive customer actions.
Rate controls
Use appropriate rate and throughput controls to reduce abuse and protect dependent systems.
Abuse prevention
Combine account verification, suppression, review and behavioral controls where misuse risk is meaningful.
Secure defaults
New credentials, environments and integrations should begin with conservative access rather than broad privileges.
Protect data through its lifecycle.
Security is not limited to storage. Collection, access, processing, retention, export and deletion all need defined boundaries appropriate to the service and customer configuration.
Data minimization
Collect and expose only information needed to operate the requested service.
Access separation
Limit access to customer and operational data according to role, project and service responsibility.
Retention
Define retention periods according to product behavior, customer configuration and applicable requirements.
Deletion
Support deletion workflows where data is eligible for removal and operational dependencies permit it.
Exports
Treat data exports as sensitive operations with appropriate authorization and auditability.
Logs
Keep logs useful for operations without unnecessarily recording secrets or sensitive payload content.
Auditability helps teams understand what changed.
When an account configuration, credential or administrative setting changes, teams need enough context to investigate the action and its operational effect.
Administrative events
Record meaningful account, access and configuration changes.
Credential events
Track creation, rotation, revocation and other important credential lifecycle actions.
Request identifiers
Use stable identifiers to trace important API and webhook activity.
Operational investigation
Correlate logs, delivery events and account changes when diagnosing incidents or unexpected behavior.
Secure development is a continuous engineering responsibility.
Application security improves when teams review architecture, dependencies, code changes and operational behavior as part of normal delivery rather than only after an incident.
Code review
Review security-sensitive changes and access paths before production release.
Dependency management
Track third-party dependencies and respond appropriately to relevant security updates.
Environment controls
Keep production credentials, configuration and data separated from development workflows.
Testing
Use appropriate application, integration and abuse-case testing around high-impact workflows.
Incident handling should prioritize containment, evidence and recovery.
When suspicious activity or a security issue is identified, the response should focus on limiting impact, preserving useful evidence, restoring safe operation and communicating with affected parties as appropriate.
Detect
Use operational signals, authentication events, error patterns and reports to identify suspicious conditions.
Contain
Restrict affected credentials, accounts, routes or services where necessary to reduce further impact.
Investigate
Use logs, account history and technical context to understand scope and root cause.
Recover
Restore service through validated configuration, credential rotation and corrective action.
Security is shared across the platform and the customer environment.
Zayloft can provide platform controls, but customers also control their own users, credentials, integrations, message content, endpoints and downstream systems.
Customer access
Customers should manage their users, roles, devices and credentials responsibly.
Integration security
Customer applications should verify events, protect secrets and handle retries and errors safely.
Endpoint security
Webhook and API endpoints remain part of the customer security boundary.
Content & audience
Customers remain responsible for the appropriateness, authorization and intended recipients of their communications.
Report a security concern responsibly.
If you believe you have identified a security issue affecting Zayloft, provide enough technical detail for the concern to be reviewed without publicly disclosing sensitive exploit information.
Include
Affected URL or service, reproduction steps, observed behavior, expected behavior and relevant timestamps.
Avoid
Do not access data that is not yours, disrupt production services or publish exploit details before the issue can be reviewed.
Contact
Send security-related reports to support@zayloft.com with “Security report” in the subject line.
Preserve context
Include request IDs, screenshots or logs when useful, but remove secrets, passwords and unrelated personal data.
Frequently asked questions
No. Security certifications and formal attestations should only be represented after they are actually completed and verified.
No. API secrets and similar credentials should remain on trusted server-side systems or protected secret stores.
Applications should validate the configured signature mechanism before trusting webhook content or triggering downstream actions.
Yes. Separating environments and credentials reduces the chance that development activity affects live systems.
No platform can guarantee the security of every customer implementation. Zayloft provides controls and secure integration patterns, while customers remain responsible for their own systems, users, credentials and endpoints.
Yes. Role, organization, project and environment boundaries are core parts of the access-control model.
No. Operational logging should avoid exposing secrets, private provider credentials or unnecessary infrastructure details to ordinary users.
Send the technical details to support@zayloft.com with “Security report” in the subject line and avoid publicly disclosing exploit information before review.
Build security into the operating model, not around it.
Use scoped access, protected secrets, tenant boundaries, signed events, secure transport and auditability as normal parts of how communications and authentication are operated.
For security or technical enquiries, contact support@zayloft.com.