Multi-Factor Authentication Policy
Organization: Sierra Digital Forge LLC Product covered: StreamWrangler (Android mobile application) Effective date: May 18, 2026 Last reviewed: May 18, 2026 Document owner: Ronald Warren, Managing Member Version: 1.0 Related policies: Information Security Policy v1.0, Access Controls Policy v1.0
⚠️ DRAFT — REQUIRES LAWYER REVIEW BEFORE PUBLICATION.
1. Purpose
This Multi-Factor Authentication Policy (“Policy”) defines how Sierra Digital Forge LLC (“Sierra Digital Forge”) authenticates users — both internal personnel and end consumers of StreamWrangler — before granting access to systems and actions that involve sensitive data, account-binding integrations, or production assets.
The Policy operationalizes the authentication requirements summarized in Section 6 of the Sierra Digital Forge Access Controls Policy and Section 5 of the Sierra Digital Forge Information Security Policy.
Objectives:
- To require multi-factor authentication on every Sierra Digital Forge personnel account that touches production-relevant systems or data.
- To define the consumer-side authentication model for StreamWrangler, including the elective step-up requirement before sensitive actions (account deletion, Trakt linkage).
- To define what constitutes a “factor” in Sierra Digital Forge’s authentication model.
- To document the identity-provider choices Sierra Digital Forge has made and the reasoning behind those choices.
2. Scope
This Policy applies to:
- All Sierra Digital Forge personnel accounts on services that hold or control production-relevant data, code, or credentials. See Sections 5.1 and 6 of the Sierra Digital Forge Access Controls Policy for the enumerated list of in-scope accounts.
- All consumer-user authentication paths inside the StreamWrangler mobile application, including the initial sign-in path, the session-continuation path on subsequent app launches, and the step-up authentication path before sensitive actions.
- All third-party authentication providers Sierra Digital Forge has integrated with to fulfill this Policy.
This Policy does NOT cover:
- Subprocessor-internal authentication for their own employees and infrastructure. Each subprocessor maintains its own MFA posture.
- Authentication inside Trakt’s OAuth flow itself. Trakt presents its own authentication user interface directly to the user; Sierra Digital Forge does not intercept, modify, or weaken Trakt-side authentication.
- Device-level authentication that the user has configured on their own Android device (lock screen, biometric enrollment), which Sierra Digital Forge does not control. Sierra Digital Forge does, however, leverage these device-level capabilities to implement application-level step-up authentication, as described in Section 8.
3. Definitions
| Term | Definition |
|---|---|
| Factor | A piece of evidence a user provides to authenticate. The three classical factor categories are knowledge (something the user knows, e.g., a password or PIN), possession (something the user has, e.g., a phone holding a TOTP app or a hardware key), and inherence (something the user is, e.g., a fingerprint or face). |
| Multi-factor authentication (MFA) | Authentication that requires at least two factors drawn from at least two different categories. A password plus an SMS code is MFA; two passwords are not. |
| Two-factor authentication (2FA) | A specific instance of MFA using exactly two factors. The terms are used interchangeably in this Policy. |
| Step-up authentication | An additional authentication challenge prompted before a sensitive action, even when the user is already authenticated for normal app use. The challenge typically requires a possession or inherence factor. |
| Federated authentication | Authentication delegated to a trusted external identity provider (e.g., Google) that authenticates the user on Sierra Digital Forge’s behalf and returns a verified identity assertion. |
| Biometric authentication | Authentication using a biological or behavioral characteristic of the user. In the StreamWrangler context, this means the Android system’s biometric subsystem (fingerprint or face) as exposed through androidx.biometric.BiometricPrompt. |
| Sensitive action | An in-application action that requires step-up authentication regardless of session state. Enumerated in Section 6.3. |
4. Roles & Responsibilities
Sierra Digital Forge is a member-managed limited liability company. All Policy roles are currently vested in the Managing Member.
| Role | Holder | Responsibility |
|---|---|---|
| Policy owner | Ronald Warren, Managing Member | Approves and maintains this Policy; signs off on identity-provider choices; defines the list of sensitive actions in Section 6.3. |
| Implementation lead | Ronald Warren, Managing Member | Implements and verifies the MFA controls described in this Policy in the StreamWrangler application. |
| Operations | Ronald Warren, Managing Member | Maintains the personnel-side MFA posture (enabling 2FA on new accounts, rotating recovery codes, etc.). |
5. MFA for Sierra Digital Forge Personnel
Sierra Digital Forge personnel-side multi-factor authentication is operational today. Two-factor authentication is enforced on every account that meets any of the criteria in Section 6.1 of the Sierra Digital Forge Access Controls Policy, including (without limitation):
- Google Cloud Console (Firebase project owner)
- TMDB Developer Dashboard
- Watchmode Dashboard
- Trakt Application Console
- Google Play Console
- Private GitHub repository hosting StreamWrangler source code
- Personal password manager that stores administrative credentials
- Developer workstation operating-system account
The password manager that holds these credentials requires its own strong master password plus 2FA. No production-relevant account is exempt from 2FA. No shared administrative accounts are used.
Detailed account-management and credential-storage requirements are documented in Sections 5, 6, and 14 of the Sierra Digital Forge Access Controls Policy.
6. MFA for Consumer Users
This Section describes Sierra Digital Forge’s authentication model for consumer users of StreamWrangler. Section 10 describes the current implementation status and the timeline by which the model is to be fully operational.
6.1 Guest mode
Guest users do not authenticate. Guest sessions are local-only; no credentials are issued or required. Guest mode has no sensitive actions in the sense of Section 6.3 because no account or backend record is bound to the guest session.
6.2 Primary authentication (registered users)
The primary authentication path for registered users uses Firebase Authentication, with both email/password and federated Google Sign-In as supported sign-in methods.
- Email/password sign-in. The user creates a Firebase Authentication record with their email address and a password. The password is transmitted to Firebase over TLS and stored as a salted hash on Firebase’s infrastructure. Sierra Digital Forge never sees the plaintext password.
- Google Sign-In. The user authenticates with their Google account. Firebase Authentication accepts the federated identity token and issues a session token for StreamWrangler use. When the user has 2FA enabled on their Google account, that 2FA is enforced at the Google identity tier and brings into the StreamWrangler authentication path automatically.
On first launch (or after a sign-out) a user who wants to access registered-mode features is prompted to sign in. The resulting identity is persisted on-device via the Firebase Authentication SDK so that subsequent app launches resume the user’s session without requiring a fresh sign-in.
6.3 Step-up authentication before sensitive actions
Authentication once at sign-in is sufficient for routine StreamWrangler use (browsing, saving to watchlist, marking episodes watched, reading Family Activity). It is insufficient for the small set of sensitive actions enumerated below.
Sierra Digital Forge requires step-up authentication before any sensitive action defined in Section 6.4. The step-up factor is a biometric authentication via the AndroidX BiometricPrompt API, with automatic fall-through to the device’s PIN, pattern, or password when biometric is not enrolled.
The combination of:
- Primary authentication through Firebase Authentication (with optional Google federation that brings Google-account 2FA into the path), plus
- Biometric or device-PIN step-up authentication immediately before any sensitive action
constitutes Sierra Digital Forge’s MFA model for consumer users. The two factors satisfy the multi-factor requirement because they come from different categories (knowledge of the account password or possession of the federated Google session + inherence via biometric, or knowledge via device PIN).
6.4 Defined sensitive actions
The following in-application actions require step-up authentication. The list is canonical and is maintained by the Managing Member. The list will be extended as StreamWrangler adds new features that touch sensitive data or initiate sensitive integrations.
| Sensitive action | Why step-up is required |
|---|---|
| Initiating Delete Account & Wipe Data | Action is irreversible; permanently destroys all on-device data and triggers backend deletion. |
| Linking a Trakt account (OAuth start) | Trakt linkage issues a long-lived OAuth token tied to the user’s Trakt account. The step-up confirms the person initiating the link is the device’s authorized user. |
| Disconnecting or relinking a Trakt account | Equivalent sensitivity to initial link. |
| Purchasing or cancelling a Premium subscription (when the Premium tier ships) | Subscription changes are billing-relevant and we want them confirmed by the device’s authorized user. (Future feature; listed for completeness.) |
| Changing the account email or password (when the App exposes this UI) | Changes to the credential bound to the account. (Future feature; listed for completeness.) |
Routine, non-sensitive actions (browsing, watchlist add/remove, marking episodes watched, publishing a Family Activity entry, tapping Watch Now) do NOT require step-up authentication. Requiring step-up for every interaction would degrade the user experience without proportionate security benefit.
7. Identity Provider Selection
Sierra Digital Forge has evaluated identity-provider options and selected Firebase Authentication (with email/password and Google Sign-In as supported methods) as the primary authentication provider for StreamWrangler. The evaluation considered:
| Provider | Suitability for StreamWrangler |
|---|---|
| Firebase Authentication | Selected. Already integrated with the Cloud Firestore data layer; supports email/password and federated Google Sign-In; Sierra Digital Forge never sees plaintext passwords; Google enforces account-level 2FA at the federated tier when the user has it enabled. |
| Google Sign-In only (no email/password) | Considered. Rejected because some users prefer not to bind a media-tracking app to their Google account. |
| Sign in with Apple | Not applicable on Android-only distribution. Could be revisited if Sierra Digital Forge releases an iOS application. |
| Custom email + password with SMS or TOTP MFA | Highest engineering cost; introduces Sierra Digital Forge as a deeper custodian of user passwords; no offsetting benefit over Firebase Authentication on a single-platform Android app. |
Sierra Digital Forge reserves the right to add additional providers (Sign in with Apple if releasing on iOS, etc.) at a later date. Any added provider will be required to enforce its own account-level 2FA at the identity tier, or to be explicitly documented as a fallback that requires Sierra Digital Forge to implement separate MFA.
8. Biometric Authentication Standards
Step-up authentication uses the AndroidX BiometricPrompt API. Sierra Digital Forge’s implementation requirements are:
- Authenticator class. The prompt requires either
BIOMETRIC_STRONG(Class 3 biometrics — fingerprint, face, iris on supported devices) orDEVICE_CREDENTIAL(the user’s device PIN, pattern, or password) as the fallback. - No biometric data stored by Sierra Digital Forge. Biometric verification is performed entirely inside the Android Keystore and the device’s hardware-backed Trusted Execution Environment. Sierra Digital Forge does not receive, store, or transmit any biometric template, image, or feature vector. The
BiometricPromptreturns a binary success/failure result; Sierra Digital Forge sees only that result. - Fallback enrollment. When biometric hardware is not enrolled on the device, the prompt automatically falls back to device PIN, pattern, or password. The user is not required to enroll a biometric to use StreamWrangler.
- Re-prompt on retry. If a biometric attempt fails, the user is re-prompted up to the system limit. After repeated failure, the prompt automatically falls back to device credential.
- No remember-me bypass for sensitive actions. Step-up authentication is required every time a sensitive action is initiated; there is no “remember this device for 30 days” affordance that would weaken the step-up.
9. Session Management
9.1 Initial session
After a successful primary authentication via Firebase, Sierra Digital Forge persists the user’s identity assertion locally so subsequent app launches do not require a fresh sign-in. The persisted identity record:
- Does not contain a plaintext password.
- Is stored by the Firebase Authentication SDK in App-private storage protected by the Android user-data sandbox.
- Can be invalidated at any time by:
- The user, by signing out from Settings.
- The user, by initiating Delete Account & Wipe Data.
- The Android system, when the user uninstalls StreamWrangler.
9.2 Step-up sessions
Step-up authentication is not cached. Each invocation of a sensitive action prompts for biometric or device credential anew. There is no “step-up valid for the next 5 minutes” shortcut.
9.3 Session-end behaviors
- Sign-out clears the persisted identity record. The next launch requires a fresh sign-in for registered-mode features. Guest mode continues to work without sign-in.
- Delete Account & Wipe Data clears the identity record together with all other user data, then signs the user out and triggers backend deletion of the user’s Firebase Authentication and Firestore records.
10. Implementation Status and Roadmap
Sierra Digital Forge has made the following commitments regarding the implementation status of this Policy. This Section is updated as implementation milestones are reached.
10.1 Current state
As of the Effective Date of this Policy:
- Personnel-side MFA (Section 5). Operational. 2FA enforced on every in-scope account.
- Consumer guest mode (Section 6.1). Operational. Guest sessions are local-only and require no authentication.
- Consumer primary authentication (Section 6.2). Operational at the Firebase Authentication tier. Email/password and Google Sign-In are wired through the existing AuthScreens flows.
- Consumer step-up authentication (Section 6.3). Not yet shipped. The dependency on
androidx.biometricwill be added; the step-up gate will be wired around each action enumerated in Section 6.4 before the first Production-track release.
10.2 Planned delivery
| Milestone | Target |
|---|---|
| Add biometric / device-credential step-up gate before each Section 6.4 sensitive action | Before the first Production-track release |
| End-to-end on-device validation of the step-up flow | Before the first Production-track release |
| Implementation status update in this Policy | Coincident with shipping each milestone |
10.3 Production-track gate
Sierra Digital Forge will not promote StreamWrangler to the Google Play Store Production track until the Section 10.2 milestones are complete and verified on device.
Internal testing and Closed testing may proceed in parallel with the step-up implementation; the Production-track gate is the hard stop.
11. Account Recovery
Account recovery for consumer users is handled at the identity-provider tier:
- A user who loses access to their Firebase email/password account uses the Firebase-provided password-reset flow (also exposed in StreamWrangler’s
forgot_passwordscreen). Sierra Digital Forge does not see passwords and cannot recover one on the user’s behalf; the user must reset. - A user who loses access to their Google account (when they used Google Sign-In) follows Google’s standard account-recovery process.
- A user who loses access to their device but retains their identity can install StreamWrangler on a new device and sign in fresh. The user’s Cloud Firestore documents are downloaded on first sign-in so their watchlist, viewing state, and Family Activity follow them across devices.
For personnel account recovery, see Section 12 of the Sierra Digital Forge Access Controls Policy.
12. Logging & Audit
12.1 Personnel authentication
Subprocessor dashboards and the developer workstation generate their own authentication logs on the vendor or operating-system side. Sierra Digital Forge does not aggregate these logs centrally because they are accessible directly from each respective console when needed for an investigation.
12.2 Consumer authentication
Firebase Authentication generates per-account sign-in audit metadata that is accessible to Sierra Digital Forge through the Firebase Console for legitimate operational reasons. The StreamWrangler application logs the following events to local Android logcat during development. None of these events are transmitted off-device in production builds.
- Sign-in attempted (success / failure).
- Sign-out invoked.
- Step-up authentication prompted (success / failure / cancelled) — once Section 10.2 lands.
- Sensitive action initiated.
The logged events do not include the user’s password, biometric data, or any credential material. They record only the event type and timestamp for purposes of on-device diagnostics.
13. Exception Process
If an operational situation appears to require a deviation from this Policy (for example, a temporary disablement of step-up authentication during a debugging session), the exception is handled per Section 15 of the Sierra Digital Forge Access Controls Policy: documented in writing in advance, approved by the Managing Member, logged with start and end timestamps, and closed promptly when the underlying need ends.
No exception has been issued since the Effective Date of this Policy.
14. Policy Review
This Policy is reviewed in full at least once per calendar year by the Managing Member. The annual review considers:
- Whether the identity-provider selection in Section 7 is still appropriate.
- Whether the list of sensitive actions in Section 6.4 reflects the current feature set of StreamWrangler.
- Whether new authentication standards or vendor requirements have emerged that warrant a Policy update.
- Whether the implementation status in Section 10 should be advanced or revised.
The Policy is also reviewed promptly on the occurrence of any of the events listed in Section 14.2 of the Sierra Digital Forge Access Controls Policy.
15. Related Documents
- Sierra Digital Forge Information Security Policy (v1.0)
- Sierra Digital Forge Access Controls Policy (v1.0)
- Sierra Digital Forge Privacy Policy (published at the URL specified in the Google Play Console listing for StreamWrangler)
- Firebase Data Processing and Security Terms
- Trakt API Terms of Service
16. Distribution & Contact
This Policy is made available to partners, vendors, and regulators on request.
Sierra Digital Forge LLC — primary contacts
| Channel | Detail |
|---|---|
| Mailing address | c/o Northwest Registered Agent LLC, 732 S. 6th St., Suite N, Las Vegas, NV 89101, USA |
| Executive email | ron@sierradigitalforge.com |
| Operations / security email | info@sierradigitalforge.com |
| Telephone (voice or text, mobile) | 702-469-7646 |
| Telephone (office) | 1-855-SIERRA (1-855-743-7772) |
| Website | www.sierradigitalforge.com |
17. Acknowledgment
I, Ronald Warren, in my capacity as Managing Member of Sierra Digital Forge LLC, attest that the personnel-side multi-factor authentication described in this Policy is operational as of the Effective Date, that the consumer-side primary authentication described in this Policy is operational, that the consumer-side step-up authentication is in development with the delivery milestones recorded in Section 10, and that the Production-track gate in Section 10.3 will be honored. I commit to maintain, review, and update this Policy in accordance with the cadences specified herein.
Ronald Warren Managing Member, Sierra Digital Forge LLC Date: May 18, 2026