Security & Trust

AuthShepherd is used for high-risk, one-time authentication migrations. Security, data minimization, and isolation are core design principles. This page explains how sensitive data is handled throughout the migration process.

Secrets & Credentials Handling

Provider credentials (Auth0, Cognito, Firebase, etc.) are stored in Google Secret Manager. Secrets are:

• Encrypted at rest
• Scoped per tenant/workspace
• Accessed only by the migration jobs that require them

No secrets are hard-coded or logged. Access is restricted using least-privilege service accounts.

Encryption in Transit

All data transmitted between AuthShepherd and authentication providers is encrypted using TLS 1.2 or higher. This includes:

• API calls to source and target authentication providers
• Data synchronization between AuthShepherd services
• Webhook and callback communications
• All user interface interactions

We enforce secure connections and do not transmit sensitive data over unencrypted channels. All external communications use industry-standard encryption protocols.

Password Handling

AuthShepherd never stores user passwords. We never receive plaintext passwords. Passwords are not logged, persisted, or inspectable.

All password verification happens inside the source authentication provider. New passwords (when required) are set directly in the target provider via their APIs.

User Data Handling

We store only the minimum user profile data required to:

• analyze migration risk
• map identities between providers
• execute the selected migration strategy

Sensitive fields are minimized. User data is scoped per tenant/workspace. No data is shared across customers.

Data Retention & Deletion

AuthShepherd is typically used for one-time migrations. Customers can request:

• deletion of a specific migration
• deletion of an entire user herd
• full tenant/workspace deletion

When requested, all user data, all provider credentials, and all logs related to that migration are securely deleted. This is supported and expected once migration is complete.

Logging & Auditability

All migration actions are logged. Logs include:

• job status
• timestamps
• errors and retries

Logs are scoped per tenant and used for troubleshooting, auditability, and post-migration verification. Logs never include secrets or passwords.

Execution Safety

Operational safeguards include:

• Migrations run as background jobs
• Rate limits are respected per provider
• Batching, retries, and backoff are built in
• Dry-runs and subset tests are supported before full execution
• Migrations can be paused or stopped

These safeguards reinforce production-safe execution and reduce risk during migration.

Compliance

AuthShepherd is designed with SOC 2–aligned controls in mind. We follow best practices around:

• access control
• encryption
• audit logging
• data minimization

We do not currently claim formal compliance unless explicitly stated.

GDPR

AuthShepherd is designed to support GDPR compliance for customers processing personal data of EU residents. Key features include:

• Data minimization: We only process the minimum user data necessary for migration execution
• Right to deletion: Customers can request deletion of all user data, credentials, and logs associated with a migration
• Data portability: Migration data can be exported and transferred as needed
• Access controls: Data is scoped per tenant/workspace with strict access controls
• Transparency: All data processing activities are logged and auditable

As a data processor, AuthShepherd processes personal data only as instructed by customers (data controllers) for the purpose of authentication provider migrations. Customers retain control over what data is processed and when.

Responsible Use & Shared Responsibility

AuthShepherd is part of a shared responsibility model. Customers control:

• which providers are connected
• what data is migrated
• when migrations are executed

We provide tooling and safeguards, but customers validate outcomes in staging and production.