Multi-Factor Authentication Policy

Organization: Sierra Digital Forge LLC Product covered: QuiltRBuddy (Windows desktop + Android, .NET MAUI) 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 QuiltRBuddy — before granting access to systems and actions that involve sensitive data, account-binding integrations, or production assets.

Objectives:

1. To require multi-factor authentication on every Sierra Digital Forge personnel account that touches production-relevant systems or data.
2. To define the consumer-side authentication model for QuiltRBuddy, including the elective step-up requirement before sensitive actions (account deletion, subscription cancellation).
3. To define what constitutes a “factor” in Sierra Digital Forge’s authentication model.
4. 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 QuiltRBuddy desktop and Android applications, including the initial Community 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.
• Authentication inside the payment processor’s hosted checkout flow itself.
• Device-level authentication that the user has configured on their own Windows or Android device. Sierra Digital Forge does, however, leverage these device-level capabilities to implement application-level step-up authentication on Android (and Windows Hello where the platform supports it), as described in Section 8.

3. Definitions

4. Roles & Responsibilities

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 (Gemini API project)
• {{PAYMENT_PROCESSOR}} administrative dashboard
• {{IDENTITY_PROVIDER}} administrative dashboard
• Microsoft Partner Center
• Google Play Console
• Private GitHub repository hosting QuiltRBuddy 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 QuiltRBuddy. Section 10 describes the current implementation status and the timeline by which the model is to be fully operational.

6.1 Offline mode

A user who uses QuiltRBuddy in offline mode (no Community sign-in, no Premium subscription) does not authenticate. Block builder, quilt layout, 3D view, cut list, and file save/open all work without an account. Offline mode has no sensitive actions in the sense of Section 6.4 because no account or backend record is bound to the offline session.

6.2 Primary authentication (Community / Premium users)

The primary authentication path for users who opt into Community or who purchase a Premium subscription uses the Community identity provider ({{IDENTITY_PROVIDER}} — currently planned as Firebase Authentication).

• Email/password sign-in. The user creates an account with their email address and a password. The password is transmitted to the identity provider over TLS and stored as a salted hash on the provider’s infrastructure. Sierra Digital Forge never sees the plaintext password.
• Federated sign-in (if available). The user authenticates with a federated provider (Google, Apple). The identity provider accepts the federated identity token and issues a session token for QuiltRBuddy use. When the user has 2FA enabled at the federated provider, that 2FA is enforced at that tier.

The persisted identity assertion is stored on-device using platform-protected storage (Windows DPAPI / PasswordVault; Android EncryptedSharedPreferences) so 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 QuiltRBuddy use (designing blocks, laying out quilts, generating cut lists, posting to Community, browsing challenges). 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 varies by platform:

• Android: AndroidX BiometricPrompt with BIOMETRIC_STRONG or DEVICE_CREDENTIAL fallback (the user’s device PIN, pattern, or password).
• Windows: Windows Hello (PIN, fingerprint, or face) when the platform supports it; password re-prompt as a fallback when Hello is not available.

The combination of:

• Primary authentication at the identity provider (with optional federated 2FA at that tier), plus
• Biometric or device-credential step-up authentication immediately before any sensitive action

constitutes Sierra Digital Forge’s MFA model for consumer users.

6.4 Defined sensitive actions

The following in-application actions require step-up authentication. The list is canonical and maintained by the Managing Member.

Routine, non-sensitive actions (designing, layout, file save/open, posting to Community, browsing challenges) do NOT require step-up authentication.

7. Identity Provider Selection

Sierra Digital Forge has evaluated identity-provider options and selected {{IDENTITY_PROVIDER}} (currently planned as Firebase Authentication) as the primary authentication provider for QuiltRBuddy. The evaluation considered:

Sierra Digital Forge reserves the right to switch providers before launch and to add additional federated providers (Sign in with Apple, etc.) later. 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 platform-native biometric prompts:

• Android: AndroidX BiometricPrompt requiring either BIOMETRIC_STRONG (Class 3 biometrics — fingerprint, face, iris on supported devices) or DEVICE_CREDENTIAL (device PIN, pattern, password) as the fallback.
• Windows: Windows Hello via the Windows Runtime APIs (UserConsentVerifier), with a password re-prompt fallback when Hello is unavailable or not enrolled.

Common implementation requirements across both platforms:

• No biometric data stored by Sierra Digital Forge. Biometric verification is performed entirely inside the platform’s hardware-backed Trusted Execution Environment / TPM. Sierra Digital Forge receives only a binary success/failure result.
• Fallback enrollment. When biometric hardware is not enrolled, the prompt falls back to device PIN / password. The user is not required to enroll a biometric to use QuiltRBuddy.
• Re-prompt on retry. Failed attempts re-prompt up to the system limit, then fall back to device credential.
• No remember-me bypass for sensitive actions. Step-up authentication is required every time a sensitive action is initiated.

9. Session Management

9.1 Initial session

After a successful primary authentication, 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 in platform-protected storage (Windows DPAPI / PasswordVault; Android EncryptedSharedPreferences).
• Can be invalidated by:
  • The user signing out from Edit > Preferences > Account > Sign Out.
  • The user invoking Delete Community Account.
  • The platform when the user uninstalls QuiltRBuddy (Android only; Windows leaves user-chosen files intact).

9.2 Step-up sessions

Step-up authentication is not cached. Each invocation of a sensitive action prompts for biometric or device credential anew.

9.3 Session-end behaviors

• Sign-out clears the persisted identity record.
• Delete Community Account clears the identity record together with all other Community data and triggers backend deletion.

10. Implementation Status and Roadmap

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 offline mode (Section 6.1). Operational. Offline sessions require no authentication.
• Consumer primary authentication (Section 6.2). In active development. The Community identity provider integration is wired structurally; full email/password and federated sign-in flows are pending the public Community release.
• Consumer step-up authentication (Section 6.3). Not yet shipped. Will be wired around each action enumerated in Section 6.4 before the first Production-track release.

10.2 Planned delivery

10.3 Production-track gate

Sierra Digital Forge will not promote QuiltRBuddy to the Microsoft Store or Google Play Store Production track until the Section 10.2 milestones are complete and verified on the target platforms.

11. Account Recovery

Account recovery for consumer users is handled at the identity-provider tier:

• A user who loses access to their Community account uses the identity provider’s password-reset flow. Sierra Digital Forge does not see passwords and cannot recover one on the user’s behalf.
• A user who loses access to their device but retains their identity can install QuiltRBuddy on a new device and sign in fresh. Community-backend records are downloaded on first sign-in.

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.

12.2 Consumer authentication

The identity provider generates per-account sign-in audit metadata accessible to Sierra Digital Forge through the provider’s console. The QuiltRBuddy application logs the following events to the local platform log facility during development:

• Sign-in attempted (success / failure).
• Sign-out invoked.
• Step-up authentication prompted (success / failure / cancelled) — once Section 10.2 lands.
• Sensitive action initiated.

Logged events do not include the user’s password, biometric data, or any credential material.

13. Exception Process

If an operational situation appears to require a deviation from this Policy, 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 QuiltRBuddy.
• 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 QuiltRBuddy)

16. Distribution & Contact

This Policy is made available to partners, vendors, and regulators on request.

Sierra Digital Forge LLC — primary contacts

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 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.

Ronald Warren Managing Member, Sierra Digital Forge LLC Date: May 18, 2026