Frequently Asked
Questions

Your applications maintain full functionality as they only require access to a CDN infrastructure. There is no direct communication between your apps and the web dashboard. Should the dashboard become unavailable, you can continue managing your certificates through our CLI, which connects directly to the API. Your applications will continue operating without any interruption.

Your applications remain fully operational as they only communicate with our CDN infrastructure, not the API directly. During an API outage, certificate modifications and updates through our management tools will be temporarily unavailable. However, for enterprise customers using Bring-Your-Own-Key (BYOK) and Bring-Your-Own-CDN configurations, emergency certificate changes can still be made even if both the API and web dashboard are unavailable. This scenario is extremely rare and provides an additional layer of resilience for mission-critical deployments.

TrustPin utilizes a globally distributed CDN with edge locations worldwide. Paid plans include a 99.9% uptime SLA for configuration delivery, measured separately from the management platform, with service credits if a target is missed. The CDN is designed to keep your certificate configurations highly available to your applications, with automatic failover across regions during outages. Because apps also continue validating against the last trusted configuration if delivery is ever unreachable, pinning keeps working even when delivery is temporarily unavailable.

With Bring-Your-Own-CDN, you have complete control over your infrastructure and certificate distribution. TrustPin supports any CDN provider capable of serving plain text files - including AWS CloudFront, Azure CDN, Cloudflare, Google Cloud CDN, and others. The only requirement is the ability to host and serve static text content, making the solution highly flexible and vendor-agnostic. You can also set your own CDN as the primary source with TrustPin's CDNs as backup, so configuration delivery stays fully within your control.

Yes. Paid plans include a 99.9% monthly uptime SLA, measured separately for the two services that matter: Configuration Delivery (the CDN that serves pins to your apps) and the Management Platform (the dashboard and API you use to make changes). Both are monitored publicly at status.trustpin.cloud. Configuration Delivery runs across redundant CDNs with automatic failover, and apps keep validating against the last trusted configuration if delivery is ever unreachable. Pinning continues for end users even during a delivery interruption. The SLA defines service credits for any month that misses the target. The SLA applies to paid plans only: the free tier is provided "as is", with no uptime commitment, no service credits and no guaranteed support response time.

Yes. The free tier is limited to one project with a limited number of domains, and it is intended for evaluation, side projects and small production workloads. Beyond those structural limits, configuration delivery is subject to fair use: your apps fetch signed configuration from shared CDN capacity that we pay for, so there is a point at which sustained traffic stops being reasonable to serve for free. We do not publish a hard cutoff. If your usage grows past what the free tier is sized for, we will contact you first and help you move to a paid plan. We reserve the right to throttle, suspend or convert accounts that generate sustained excessive load, or that shard workloads across multiple free accounts to avoid plan limits. Paid plans add higher project and domain limits, a 99.9% uptime SLA with service credits, and support commitments, none of which apply to the free tier.

TrustPin establishes a secure, cryptographically-verified communication channel between your applications and a trusted configuration source. Using public key cryptography, only parties holding your signing keys can modify certificate information, which lets applications cryptographically verify both the integrity and authenticity of what they receive. Our system performs certificate pinning by validating certificate fingerprints and Certificate Transparency logs. Unlike traditional approaches that embed static certificates in your application, TrustPin dynamically retrieves and verifies certificate information, providing strong protection against man-in-the-middle attacks while maintaining operational flexibility.

Each TrustPin project uses isolated signing keys, limiting the blast radius of any potential compromise. In the unlikely event of key compromise, you can immediately create a new project with fresh signing keys and migrate your applications in under 5 minutes. As an additional security measure, we can remove compromised configurations from our CDN infrastructure, preventing applications with compromised keys from accessing pinning services. This multi-layered security approach ensures rapid recovery and minimal exposure.

TrustPin enhances security by cross-referencing Certificate Transparency (CT) logs with certificate validation. Beyond standard certificate hash verification, our system validates that the CT logs declared by the server match those recorded in the certificate's extensions. This additional layer of verification helps detect fraudulent certificates and ensures that only legitimate certificates, properly logged in public CT databases, are accepted by your applications.

Each TrustPin project contains only three pieces of embedded information: Organization ID, Project ID and Public Key. When creating a new project after a compromise, you have two deployment options: release a new application version with updated credentials, or use remote configuration (which we strongly recommend) to update these values instantly without requiring app store submissions or user updates. This architecture minimizes embedded dependencies while maintaining maximum security and operational flexibility.

Customer account and configuration data is hosted in the European Union (databases and APIs in Frankfurt, the mobile configuration origin in Ireland), supporting GDPR and EU data residency. TrustPin does not store application end-user data or PII; we hold only certificate configurations, project metadata, and your account information. The one nuance worth stating plainly: like any networked service, the global CDN edges that deliver public configuration may transiently process the IP address of a device fetching it. We publish the full list of infrastructure sub-processors and can provide our GDPR Data Processing Agreement (DPA) on request; see our Security page for details.

Since TrustPin does not store end-user data, GDPR data subject access requests (DSARs) for your application users do not require action from TrustPin. Only your organization's account data (email, project configurations) is stored in our systems. If you need to delete your organization's data, you can do so directly from the dashboard, or contact support for complete account deletion. Account data is permanently removed within 30 days of account closure; operational audit logs are retained for up to one year.

All connections use TLS 1.2+ with HSTS and Certificate Transparency (A+ SSL Labs rating), and data is encrypted at rest. Pinning configurations are signed with ECDSA P-256 and verified on-device against a published JWKS, so a forged or tampered configuration is rejected before any pin is trusted. Pins use SHA-256 or SHA-512 hashes, and with Bring-Your-Own-Keys (BYOK) you can sign configurations with your own private key so cryptographic trust never leaves your organization.

No - they solve different problems and complement each other. TrustPin's certificate pinning secures the connection between your app and your servers, blocking man-in-the-middle attacks at the TLS handshake. RASP protects the app itself at runtime against hooking, code injection, tampering, and repackaging - attacks that happen inside the app process where pinning cannot see them. For that layer, TrustPin partners with Promon, a pioneer of app shielding whose technology protects apps for banks and governments worldwide. Combining both gives you defense-in-depth: each layer protects what the other cannot reach. Learn more at trustpin.cloud/partners/promon.

We welcome coordinated disclosure. Report suspected vulnerabilities privately to security@trustpin.cloud; we will acknowledge promptly, investigate, and keep you updated through resolution before any public disclosure.

TrustPin integration typically takes just a few minutes and follows a simple 3-step process: create your project in the dashboard, configure the domains you want to protect, and integrate our lightweight SDK. The SDK requires only a single setup function call. On some platforms, this setup call automatically handles all certificate pinning, while others may require adding one or two additional lines to your existing HTTP client configuration. This minimal integration approach ensures rapid deployment without disrupting your existing architecture.

Yes, TrustPin is designed to work in enterprise environments with TLS inspection infrastructure. While TrustPin normally protects against certificate manipulation (including corporate proxies that replace certificates), you can configure custom certificate fingerprints for specific domains. This allows enterprises to implement certificate pinning for external services using their own inspection certificates rather than the original certificates. Our dashboard provides tools to either fetch certificate information from your corporate environment or manually add custom fingerprints as needed.

The TrustPin setup requires four parameters: Organization ID, Project ID, Public Key, and Configuration URL (the latter only for Bring-Your-Own-CDN deployments). These identifiers are safely embedded in your application as they contain no sensitive secrets - the public key is cryptographically designed to be publicly known. While TrustPin covers certificate pinning end to end, we recommend implementing Runtime Application Self Protection (RASP) as part of a defense-in-depth security strategy - which is why TrustPin partners with Promon, whose app-shielding technology provides exactly that runtime protection layer. See trustpin.cloud/partners/promon for details.

Here's a practical example: Suppose your application connects to api.example.com, but your corporate proxy intercepts this traffic with its own certificate. You would configure TrustPin to pin api.example.com using your corporate proxy's certificate fingerprint rather than the original certificate from api.example.com. When your corporate certificate rotates, you simply update the fingerprint in TrustPin instead of managing the external domain's certificate. This approach ensures your applications remain secure while respecting corporate network policies and compliance requirements.

TrustPin proactively prevents certificate expiration issues. Simply configure TrustPin with your new certificate before the current one expires, or immediately upon receiving your replacement certificate. Our system supports multiple certificates per domain, allowing for smooth transitions. Once you deploy the new certificate to your server, TrustPin automatically validates it against the pre-configured certificate information, ensuring uninterrupted application functionality without any user intervention.

TrustPin eliminates embedded certificates entirely. Instead of hardcoding certificates in your application, TrustPin uses cryptographically signed configuration files hosted remotely. Your application dynamically retrieves and verifies these configurations using your signing keys, ensuring authenticity and integrity. This architecture enables instant certificate updates without app store submissions, user downloads, or application restarts - delivering true zero-downtime certificate rotation. TrustPin fully supports managed certificates from providers like AWS Certificate Manager, Cloudflare, Let's Encrypt, DigiCert, and others, allowing you to benefit from automatic certificate rotation while maintaining robust certificate pinning.

Yes, TrustPin fully supports certificates from all major certificate authorities including Let's Encrypt, AWS Certificate Manager (ACM), Cloudflare, DigiCert, and any other CA. TrustPin uses SPKI (Subject Public Key Info) pinning, which is the OWASP-recommended industry best practice for certificate pinning. It's important to note that most managed certificate services (including Let's Encrypt, AWS ACM, and Cloudflare) generate new key pairs when renewing certificates by default, which means the SPKI hash changes with each renewal, just like leaf certificate hashes. This is standard secure practice. TrustPin's dynamic pinning is essential for working with these services - it allows you to update pinned certificates remotely without app releases, enabling zero-downtime rotation regardless of whether keys change. Optional: If you want SPKI hashes to remain stable across renewals (avoiding the need to update pins), you can configure your certificate provider to reuse the same private key. For example, with Let's Encrypt via Certbot, use the --reuse-key flag when renewing: 'certbot renew --reuse-key'. This generates a new certificate with the same public key, keeping your SPKI pins valid. Note that AWS ACM does not support key reuse - it always generates new keys during renewal, so you must use TrustPin's dynamic pin updates.

TrustPin imposes no technical limits on certificates per domain, providing complete flexibility for complex certificate management scenarios. The only constraints are organizational: the number of projects per organization, domains per organization, and organization creation capabilities. These limits are plan-dependent and designed to support everything from individual developers to large enterprise deployments. This unlimited certificate approach enables advanced use cases like A/B certificate testing, gradual rollouts, and complex multi-certificate architectures.

TrustPin optimizes performance through intelligent caching: configuration files are cached in application memory for 10 minutes and fetched before the first network request, refreshing in the background when the cache expires. If a fetch fails, or the CDN is temporarily unreachable, the SDK keeps validating against the last trusted configuration already on the device, so certificate pinning continues without interruption. Anti-rollback protection additionally ensures a stale or downgraded configuration can never silently weaken your pinning.

TrustPin is built upon the foundational OWASP research that specifically recommends dynamic certificate pinning over static embedded certificates. We have evolved beyond the original specifications by incorporating enterprise-grade features including configuration versioning, cloud-native infrastructure, broad SDK support, command-line tools, and Certificate Transparency integration. TrustPin meets the OWASP mobile security recommendations and goes further to address the real-world operational challenges they leave open.

Yes. TrustPin supports security audits through formal NDA agreements that provide read-only access to our source code repositories. Organizations can audit our SDKs, command-line tools, and API implementations to ensure they meet internal security standards. For enterprises with specific compliance requirements, we also offer specialized contracts including on-premises deployment options and additional security features tailored to your organizational needs.

TrustPin does not currently hold its own SOC 2 or ISO 27001 certification. Instead, the platform runs entirely on SOC 2 / ISO 27001-certified infrastructure providers (DigitalOcean, AWS, and Vercel), so the underlying physical, network, and platform controls are inherited from certified providers. On top of that, TrustPin is built to the OWASP MASVS, follows privacy-by-design data-minimization principles aligned with GDPR and CCPA, hosts platform data in the EU, and collects no identifying data about your app's end users, keeping your assessment scope small. For a vendor review we provide a security package: a security whitepaper, a completed security questionnaire (CAIQ), our DPA, and SLA, all available under NDA. See our Security page or contact us to request it.

Yes. We provide a GDPR Article 28 Data Processing Agreement (DPA). Customer data is hosted in the EU; where data is processed by US-based infrastructure sub-processors (such as our hosting, web, and identity providers), transfers are covered by the EU Standard Contractual Clauses (SCCs). Account email is handled by a Swiss provider under the EU's adequacy decision for Switzerland. A current sub-processor list is available on request.