Security Overview
Last updated: April 3, 2026
We do not claim PassMyBits is "unhackable" or "100% secure". We do treat security as continuous work: build carefully, monitor actively, and improve when we learn.
How we approach security
Security is part of product development, operations, and support. We combine automated checks, regular testing, monitoring, backups, and human review so issues can be caught early and handled responsibly.
Zero-knowledge and encryption
PassMyBits is designed around a zero-knowledge approach. Sensitive data is end-to-end encrypted, and we keep as little data unencrypted on the server as possible. Encryption keys are not stored on our server and are not sent to our server. Customers are responsible for keeping those keys safe and recoverable themselves. That means PassMyBits does not have access to the contents of that sensitive data and cannot recover those keys for users. At the same time, selected content and text fields can be analysed locally on the user device before encryption where this is necessary for abuse prevention and moderation.
Abuse prevention and moderation
PassMyBits combines local client-side scanning, metadata review, rate limits, and manual follow-up on signals or reports so the service can be protected without routine plaintext disclosure to third-party scanners.
- Selected text, PDF text layers, image OCR, and sampled video frame OCR can be scanned locally before encryption/upload.
- Routine moderation uses signals, reports, metadata, and logs rather than broad server-side reading of user content.
- High-risk cases can lead to temporary blocking, suspension, or escalation for legal and safety reasons.
- Questions, context, or objections can be sent to security@passmybits.com or info@passmybits.com.
Extra protection for trustee access
Trustee access now uses a stepped flow. A trustee first needs the PDF token and trustee password to start the request. After the timelock ends, the trustee must enter the token and trustee password again before the existing Pass password can be used locally to decrypt the contents. Repeated failed trustee verification or decryption attempts can restart the timelock, invalidate active trustee grants, and notify the Pass owner.
What this means in practice
- Changes go through code review and automated checks before release.
- We test the application, API, and configuration regularly, including outside the production environment.
- We monitor relevant security signals such as suspicious activity, scan findings, and operational alerts.
- Suspicious login behavior, brute-force attempts, and abusive traffic can trigger alerts and automated blocking.
- Security-relevant application events are logged centrally, and higher-risk events notify our security mailbox.
- Access to sensitive systems and production actions is kept limited and traceable.
- Backups, malware hygiene checks, and recovery procedures are part of routine operations.
What we pay extra attention to
- Protecting accounts, login flows, and two-factor authentication.
- Keeping user data separated so people only access what belongs to them.
- Reducing the chance of leaked secrets, unsafe dependencies, or risky configuration changes.
- Reviewing findings and following up with fixes, retests, and improvements.
Responsible disclosure and contact
Found a vulnerability? Report it to security@passmybits.com with reproduction steps, impact, and supporting evidence.
- We acknowledge reports within 3 business days.
- Please avoid data exfiltration, service disruption, or social engineering.
- Please do not publish details until a coordinated fix or disclosure timeline is agreed.
- Primary contact: security@passmybits.com
- For urgent operational escalation, use the subject "SECURITY INCIDENT".
Security is an ongoing process. As our service evolves, we continue adjusting controls, tests, and response procedures.