Security is not an option, it’s our priority.


For us at SEECURA, security is not an option but an absolute priority and an essential component of our platform at all levels. Seecura entrusts all data to a Server with IaaS and IDS firewalls, as well as integrated security measures up to the login page.

As sensitive data is stored, shared, and transmitted through our app, we consider security an integral part of our operations. This includes regular app and operating system updates and implementing 2FA logins for all users. 

The application does not hold any data. Seecura collects users’ orders and immediately transmits them using an HTTPS protocol (HyperText Transfer Protocol over Secure Socket Layer) to the final destination server. This guarantees our users that, in the event of unauthorized access to the app, their information will not be visible in any way — simply because it is not there! 

In other words, anyone who manages to access a phone and enter the Seecura app illegally will only see a list of final wishes without any content.

For this reason, Seecura doesn’t allow remote access to any entrusted information or documents, not even by its owner.

Final wishes cannot be recovered once submitted. Users must cancel and resubmit to amend or review them.

Where are the final wishes stored?
All data is stored in a cloud, in turn, protected within a server with the highest level of safe and anti-intrusion systems. 


SEECURA guarantees the highest security standard.


Our cloud guarantees the highest security standards for protecting stored information and against intrusion. Specifically:


Each server used by Seecura is equipped with a firewall that allows access only to specific ports necessary for application operation. 

Access security

For our users, throttling SSH and SFTP logins is a simple but effective method of dealing with brute-force logon attacks.

Bot protection
Protection from traffic congestion caused by malicious bots, brute-force login attacks, and Denial-of-Service (DoS) attacks.
Database protection
By default, the database cannot be accessed remotely.
Application isolation
Each application is isolated from the rest, thus preventing application-level problems from compromising the entire server.
SSL certificates
Our servers provide all users with FREE Let’s Encrypt SSL certificates to ensure the security of application data in transit.
User role management
Primary account holders can set up custom server access lists to provide access to server functionality as and when needed.
Operating system security and patching
Our servers are powered by Debian, in part due to its powerful and fast patch management system. Teams of engineers regularly follow the Debian community to stay up to date on current issues/vulnerabilities, and patch customer servers as soon as the patch is available.
Compliance with GDPR
Our compliance with the requirements of the European Data Protection Regulation (GDPR), the Californian Consumer Privacy Act (CCPA) and the LGDP (Brazilian data protection law) is just another demonstration of our commitment to the security of customer data and of our large customer base around the world.
Two-factor authentication
Access to our platform is secured with industry standard two-factor authentication (2FA) to strengthen platform security and minimize unauthorized access incidents on user accounts.
End-to-end encryption
The platform is fully protected with end-to-end encryption which ensures that all data in transit is protected and encrypted with the HTTPS protocol, preventing access to data while being transferred between systems.
Access control for suspicious devices

There is a control system for all devices that try to access a user’s account. If a device or login attempt is marked as Suspicious, the user is notified by email, the login process is aborted, and appropriate actions are taken to verify identity. 

Periodic security patches
We regularly deploy operating system patches and firmware updates on your server. This ensures a secure Managed Cloud server and avoids vulnerabilities.


Everything is encrypted.


Our cloud is stored inside a server with server-side encryption to protect inactive data. Server-side encryption is applied only to object data, not object metadata. Using server-side encryption with customer-supplied encryption keys (SSE-C) allows the definition of a user’s own encryption keys. With the encryption key provided as part of the request, the server handles encryption, writing to disks, and decryption when objects are accessed. Therefore, a user doesn’t need to keep any code to encrypt and decrypt the data. The only thing to do is to manage the encryption keys provided. 

Our server does not store the provided encryption keys. Instead, it stores an HMAC value of the encryption key with the introduction of a random salt to validate future requests. The HMAC value with the introduction of a salt cannot be used to derive the encryption key value or to decrypt the contents of the encrypted object. This means that if a user loses the encryption key, they lose the object. 

  • The ETag in the response is not the MD5 of the object data.
  • A user can manage the mapping themselves to keep track of the encryption key that was used to encrypt a particular object. Amazon S3 does not keep encryption keys. A user is responsible for tracking each encryption key provided for each particular object.
  • If a user’s bucket supports the Multiple Versions feature, each object version uploaded using this feature can have its own encryption key. The user is responsible for tracking each encryption key used for each particular object.
  • Since the user manages the encryption keys on the customer side, they also manage any additional safeguards, such as key rotation, on the customer side.

If the encryption key is lost, any GET request for a given object without the respective encryption key fails and the object is lost.


Download on the App Store Get it on Google Play