# Did not meet TRUSTED criteria This build did not satisfy all of CITT's published criteria for the TRUSTED mark. The full criteria and this app's results are shown below. ## Trust Pillars - **Secure by Design**: Not met. Did not meet one criterion in this area. - **Data Minimization**: Not met. Did not meet one criterion in this area. - **Manifest Mismatch**: Not met. Did not meet one criterion in this area. - **User Control**: Strong. Strong result in this area. - **Truly Local**: Not applicable. Does not apply to this app. - **Child-Safe**: Not applicable. Does not apply to this app. --- # Security & Privacy Scorecard ## Wagoneer Wagoneer is FCA/Stellantis's companion app for enrolled, properly equipped Wagoneer vehicles. It offers remote vehicle commands such as lock, unlock, and remote start; service history and recall alerts; dealer scheduling; and in-vehicle entertainment integration. Use requires an active subscription and a properly equipped, enrolled vehicle, and some features extend to a paired Wear OS smartwatch. ## What This Means for You Build 1214 accepts an invalid server certificate on the card-enrollment, marketplace, and NFT browsing screens instead of stopping the connection, and the code that starts a vehicle command sent from a paired smartwatch does not confirm which watch app sent the request. Analytics and marketing services from Adobe and Salesforce initialize in code paths that run ahead of a recorded consent decision, in the version reviewed. ## Recommendation: Solid Wagoneer verifies the server certificate against a trust list built into the app for its core FCA/Stellantis backend traffic, and the local database holding vehicle and account information uses a randomly generated password rather than a fixed one. Card-enrollment, marketplace, and NFT browsing screens accept an invalid server certificate instead of rejecting it in the production code path reviewed, and the code that starts a vehicle command from a paired smartwatch does not confirm which watch app sent it; live network and Wear OS behavior were not independently tested. The app is well suited for checking vehicle status, service history, and dealer information; card enrollment and watch-triggered remote commands warrant more caution. **Best For:** Vehicle owners who want to check vehicle status, service history, and recall and dealer information, and who want to use remote vehicle commands such as lock, unlock, or remote start from the primary phone app. ## Method and Limitations Static analysis only. CITT reviewed the code of this build without running the app, so runtime behavior was not observed. The findings below describe the analyzed build and may not reflect server-side controls or later versions. CITT makes no determination about compliance with any law or platform policy; it reports what the artifacts contain and cites the published guidance so a reader can compare. ## Key Findings **Data Security** - 1 finding (1 low) **Network Security** - 5 findings (2 high, 1 medium, 2 low) **Code Safety** - 5 findings (3 medium, 2 low) **Privacy** - 0 findings ## Privacy Concerns ### What Leaves the Device - Device and app lifecycle data: shared with Adobe Experience Platform Analytics; the code path reviewed shows this may begin before a consent choice is recorded. - Push and engagement data: shared with Salesforce Marketing Cloud, which the code initializes through both a component that starts automatically at launch and a separate direct call. - Advertising identifier: the app declares ad-attribution permissions that may link an advertising identifier to a signed-in vehicle owner; this was not observed at runtime. - Location, personal information, and other categories: per the app's Google Play Data Safety label, may be shared with third parties. ### What Stays on the Device No sensitive data was identified as processed only on the device in this analysis. Vehicle, location, and account information is encrypted locally (see Positive Security Features) but also synchronizes with the app's backend services as part of normal vehicle-connectivity operation. ### Third-Party Data Sharing **Third parties that may receive data from the app:** - Adobe Experience Platform - analytics, identity, and marketing profile data - Salesforce Marketing Cloud - push notifications and marketing campaign delivery - Firebase (Google) - crash reporting, push delivery, remote configuration, and performance monitoring - Facebook - social and advertising integration - Google Play Services / Measurement - analytics - SAP Gigya - customer identity and account management - OneTrust - consent preference management - DQUID - in-car audio search and playback integration ## Understanding the Scores **Security:** 68/100 **Privacy:** 82/100 ### Security Breakdown - **Data Security:** 84/100. The local database that stores vehicle and account information, including location history, trip history, glovebox documents, and remote-operation history, is encrypted with a randomly generated password, and vehicle list data is protected using the device's secure hardware-backed key storage. The step that encrypts the database password itself reuses a fixed randomizer value instead of a new one each time, a minor weakness in an otherwise well-protected design given the underlying key material stays inside the device's secure hardware. - **Network Security:** 69/100. Connections to FCA and Stellantis backend servers verify the server certificate against a trust list built into the app, which helps block simple network interception for that core traffic. Three in-app browser screens (card enrollment, the marketplace, and NFT browsing) accept an invalid server certificate rather than stopping the connection in the production code path reviewed, and a bundled in-car audio service connects to its message broker without an encrypted connection using a fixed username and password shared across every installation. Live network testing was not performed to confirm how these paths behave in the field. - **Code Safety:** 75/100. A broadcast receiver used for dealer-link enrollment accepts messages from any other installed app without an access restriction, and its check on the message's source has no effect on the code that follows it, so enrollment data is processed regardless of that check. A debug menu can also be turned on in the production build by flipping a remote configuration value, which would require access to the developer's remote-configuration project to trigger. ### Privacy Breakdown - **Data Collection:** 79/100. The app requests a broad set of permissions, including calendar, contacts, camera, and precise location, consistent with its role coordinating vehicle, service, dealer, and entertainment features; not every requested permission was confirmed as exercised by the code reviewed. - **Data Sharing:** 90/100. Third-party data sharing is concentrated among a defined set of first-party marketing, analytics, and vehicle-platform partners (Adobe, Salesforce, Firebase, Stellantis infrastructure) rather than a broad or unfamiliar set of advertising networks. - **User Control:** 78/100. A consent management platform (OneTrust) is present in the build to gate data collection choices, and the Play Data Safety label confirms deletion requests are supported. The analytics and marketing initialization code paths reviewed run ahead of that consent gate being confirmed, which limits how much control the gate provides in the paths reviewed. ## Positive Security Features - Connections to FCA and Stellantis backend servers verify the server's certificate against a trust list built into the app, rather than relying only on the device's default trust list, helping block simple network interception for that traffic. - The local database holding vehicle and account information (location history, trip history, glovebox documents, remote-operation history) is encrypted using a randomly generated password rather than a fixed one. - Vehicle list information stored on the device is protected using the device's secure hardware-backed key storage. ## Areas for Improvement ### Disclosure observations Observations about disclosure, each stated against the published guidance so a reader can compare: 1. **Google Play Data Safety Label and Bundled Services** The Google Play Data Safety label for this app (retrieved 2026-08-15) states: "This app may share these data types with third parties: Location, Personal info and 7 others" and "This app may collect these data types: Location, Personal info and 6 others." The reviewed build bundles Adobe Experience Platform Analytics and Salesforce Marketing Cloud, both initialized in code paths that run ahead of the app's own consent gate in the paths reviewed. Whether these specific code paths map to the categories disclosed on the label could not be determined from the code alone. 2. **Consent Timing for Analytics and Marketing Services** Google's Play Console Data Safety guidance (https://support.google.com/googleplay/android-developer/answer/10787469) asks developers to disclose data collection accurately. The reviewed build includes Adobe Experience Platform Analytics and Salesforce Marketing Cloud initialization code that runs before a consent decision from the app's consent management platform is recorded in the paths reviewed. Live consent-gating behavior at runtime was not tested, so how this resolves in the field could not be confirmed. ### Security Enhancements 1. **In-App Browser Certificate Handling** Recommend adjusting the browser components used for card enrollment, the marketplace, and NFT browsing so that an invalid server certificate always stops the connection rather than allowing it to proceed. 2. **In-Car Audio Service Connection Security** Recommend enabling an encrypted connection for the in-car audio service's message broker, and issuing a unique username and password per installation rather than one shared value used by every installed copy of the app. 3. **Dealer-Link Message Handling** Recommend restricting the dealer-link enrollment receiver so it only accepts messages from trusted senders, and fixing the source-address check so it has an actual effect on whether enrollment data is processed. 4. **Wear OS Command Sender Verification** Consider adding a check on the phone side confirming which watch app sent a remote-command message, in addition to confirming which watch device sent it. ## Technical Context **App Type:** Connected-vehicle companion app handling location, vehicle remote-control commands, and payment card enrollment (elevated sensitivity) **Classes Analyzed:** 29,249 **Third-Party Services:** 23 **Context Tags:** financial, location, sensitive_data, ads --- ## About This Analysis This security analysis was conducted by CITT (Can I Trust That), an independent security analysis service. The analysis is static code review of Android applications, intended to help people make informed decisions about app security and privacy. ### App Details **Developer:** FCA US LLC **Version:** 1.99.704 (1214) **Analysis Date:** 2026-08-15 **Package:** com.fca.myconnect.wagoneer.nafta ### Analysis Limitations - Static analysis only (code review without running the app) - Based on APK version 1.99.704 analyzed on 2026-08-15 - May not reflect server-side security controls - Cannot detect all runtime behaviors