This section describes the core security principles and mechanisms used by the Digital Post Platform.
It explains how identities are protected, how data is secured, and how access is controlled throughout the message lifecycle.
The goal is to provide integrators with a clear understanding of how security is implemented at a conceptual level.
The platform security model is designed to support the following objectives:
- Confidentiality of message content
- Integrity of data and metadata
- Authentication of systems and users
- Authorization of operations
- Traceability and auditability
- Protection against unauthorized access
All technical controls support these objectives.
Security is implemented across multiple layers:
- Identity and authentication
- Authorization and access control
- Transport security
- Storage security
- Application level validation
- Operational monitoring
Each layer contributes to overall system protection.
No single control is relied upon in isolation.
All access to platform APIs requires authenticated identities.
Two primary identity types exist:
- System identities for machine to machine integration
- User identities for interactive access
System authentication is based on:
- X509 client certificates
- JSON Web Tokens
- OAuth 2.0 token exchange
Each system integration represents a unique technical client.
User authentication uses external identity providers through standardized protocols.
Machine authentication is based on public key cryptography.
Each system integration is associated with:
- A public certificate stored by the platform
- A private key held by the integrator
The private key is used to sign authentication tokens.
The platform validates signatures using the registered public certificate.
Private keys must never be shared.
Loss or compromise of a private key requires immediate revocation.
Authentication establishes identity.
Authorization determines what actions are permitted.
Authorization is enforced using:
- Organisation context
- Sender identity
- System integration permissions
- API scope restrictions
Permissions are evaluated for each request.
Access is limited to resources owned by the authenticated organisation.
Cross organisation access is not permitted unless explicitly configured.
Access control is aligned with the organisational model.
Permissions are inherited through the hierarchy.
This ensures that:
- Sub organisations cannot exceed parent permissions
- Reporting boundaries are preserved
- Billing data remains isolated
- Audit visibility is controlled
Understanding the organisational model is required to understand authorization behavior.
All external communication uses encrypted transport channels.
This includes:
- TLS secured HTTPS endpoints
- Certificate validation
- Secure cipher suites
Unencrypted connections are not supported.
Clients must verify server certificates to prevent interception.
Message content and metadata are protected at rest.
Storage protection includes:
- Encrypted file storage
- Encrypted databases
- Key management controls
- Restricted administrative access
Each message body and attachment is encrypted with a unique key.
Encryption keys are not shared between messages.
Integrators may optionally encrypt files before upload.
When client side encryption is used:
- Files are encrypted using AES 256
- Encryption keys are managed by the integrator
- Keys are provided during delivery creation
The platform decrypts content for processing and re encrypts it for recipients.
This provides additional protection when using external storage services.
Each message is processed individually.
Message level protection includes:
- Envelope validation
- File integrity checks
- Hash verification
- Encryption per artifact
- Recipient isolation
Messages are never shared between recipients.
Each recipient receives an independent encrypted copy.
Data integrity is enforced through multiple mechanisms.
These include:
- Digital signatures on authentication tokens
- Hash values in envelopes
- Transport encryption
- Encrypted storage
If integrity checks fail, processing is aborted.
Corrupted messages are not delivered.
All uploaded content is scanned before delivery.
Scanning includes:
- Virus detection
- Malware analysis
- Signature matching
- Behavioral analysis
If malicious content is detected:
- Processing stops
- The envelope is rejected
- An error is recorded
Infected content is never delivered.
Messages stored in the interim repository are protected using the same controls as delivered messages.
This includes:
- Encryption
- Access isolation
- Limited retention
- Controlled notifications
Only the intended recipient may access interim messages after account creation.
Security relevant events are logged throughout the platform.
Logged events include:
- Authentication attempts
- Token exchanges
- Delivery creation
- Processing failures
- Access operations
- Administrative changes
Logs are protected from modification.
Audit records support compliance and incident analysis.
The platform continuously monitors operational and security signals.
Monitoring includes:
- Authentication anomalies
- Excessive failures
- Unusual access patterns
- Traffic spikes
- System integrity signals
Alerts are generated when thresholds are exceeded.
Detected incidents are investigated according to internal procedures.
Each organisation operates in an isolated context.
Isolation applies to:
- Message content
- Metadata
- Logs
- Reports
- Billing data
No organisation can access another organisation’s data.
Isolation is enforced at multiple technical layers.
Error responses are designed to minimize information exposure.
Responses include:
- Standardized error codes
- High level descriptions
- Correlation identifiers
Internal system details are not exposed.
Sensitive information is never returned in API responses.
Cryptographic keys are managed using controlled processes.
This includes:
- Secure generation
- Restricted access
- Rotation policies
- Backup procedures
- Revocation mechanisms
Key access is limited to authorized platform components.
Integrators are responsible for protecting their own private keys.
Security controls support regulatory requirements in applicable markets.
This includes:
- Data protection regulations
- Financial compliance rules
- Audit obligations
- Retention policies
Specific regulatory obligations are defined by platform holders.
Security is shared between the platform and integrators.
Platform responsibilities include:
- Infrastructure protection
- Core encryption
- Access enforcement
- Monitoring
- Incident response
Integrator responsibilities include:
- Protecting private keys
- Securing integration systems
- Managing credentials
- Implementing secure storage
- Monitoring integration behavior
Failure on either side may impact security.
Recommended practices include:
- Store private keys in secure hardware or vaults
- Rotate certificates regularly
- Monitor authentication failures
- Validate all responses
- Protect access tokens
- Implement least privilege permissions
- Log integration activity
- Review audit reports
These practices improve overall system security.
This section complements:
- Authentication Setup
- Organisational Model
- Message Lifecycle
- Delivery Model
- Error Handling
Together, these sections describe how the platform maintains trust and protection.
For more information, see:
- Authentication Setup
- Message Lifecycle
- Message Delivery Model
- Error Handling Guide
- API Reference