# 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 ## Navy Federal Credit Union ## What This Means for You The Android build links analytics and marketing SDKs from Firebase, Adobe, and Salesforce that send usage and session data to those companies; financial account access data and biometric authentication stay on the device in hardware-backed secure storage. ## Recommendation: Trustworthy CITT rates this app Trustworthy (81/100) for Navy Federal members. Hardware-backed authentication key storage, device tamper detection, and globally enforced HTTPS with strict server-side connection verification on the primary banking API provide strong protection for mobile banking. Analytics and marketing integrations from Firebase, Adobe, and Salesforce are the primary third-party data relationships in this build. **Best For:** Navy Federal Credit Union members who need full-featured mobile banking, including account management, card controls, remote check deposit, and loan applications. ## 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:** 4 findings (1 high, 2 medium, 1 low) **Code Safety:** 4 findings (2 medium, 2 low) **Privacy:** 0 findings ## Privacy Concerns ### What Leaves the Device - Usage and session analytics: sent to Firebase Analytics (Google) for app performance measurement - Crash reports and diagnostics: sent to Firebase Crashlytics (Google) for reliability tracking - Session data: sent to Firebase Sessions (Google) - Push notification registration data: sent to Firebase Cloud Messaging (Google) to enable push alerts - App usage events: sent to Adobe Analytics for behavior measurement - Marketing engagement data: sent to Salesforce Marketing Cloud for push notification personalization; the binary also links AltBeacon, which may send Bluetooth proximity signals to Salesforce - Device risk signals: routed through Navy Federal's own servers to Akamai CyberFend and ThreatMetrix (LexisNexis Risk) for fraud detection - Location queries: sent to Google Maps and Google Places when the ATM and branch locator is used - Payment data: processed by Fiserv / Zelle for peer-to-peer transfers - External bank account data: processed by Yodlee / Envestnet for account linking - App diagnostics: sent to Azure AppCenter for monitoring - Google Advertising ID: the binary links Google's advertising identifier framework; whether this identifier is included in off-device data was not verified in this analysis ### What Stays on the Device - Biometric authentication data (fingerprint): handled by Android's on-device biometric system and does not leave the device - Authentication keys: stored in hardware-backed secure storage on the device and not transmitted to third-party servers ### Third-Party Data Sharing **Third parties that may receive data from the app:** - Firebase (Google) - analytics, crash reporting, session tracking, and push notifications - Adobe Analytics - app usage measurement - Salesforce Marketing Cloud - marketing engagement, push notification personalization, and beacon proximity detection (AltBeacon) - Google Maps / Google Places - ATM and branch location search - Google Pay / Wallet - payment integration - Qualtrics - in-app surveys and feedback - LaunchDarkly - feature configuration management - ThreatMetrix (LexisNexis Risk) - fraud detection, routed via Navy Federal's servers - Akamai CyberFend - device risk assessment for fraud detection - Fiserv / Zelle - peer-to-peer payment processing - Yodlee / Envestnet - external bank account linking - Azure AppCenter - app telemetry and monitoring - Backbase - digital banking framework (primary banking UI and API layer) ## Understanding the Scores **Security:** 78/100 **Privacy:** 88/100 ### Security Breakdown - **Data Security:** 90/100. App data is excluded from Android cloud and ADB backup channels, and authentication keys are stored in hardware-backed secure storage, keeping account access data on the device. - **Network Security:** 83/100. HTTPS is enforced globally for all banking traffic, and the primary banking API applies framework-level server connection verification. Four findings were identified in URL routing configuration, including one high-severity item; details are in Areas for Improvement. - **Code Safety:** 85/100. ProGuard obfuscation protects the core banking logic, and device tamper detection prevents login on compromised devices. Several development and test artifacts are present in the production build, covered in Areas for Improvement. ### Privacy Breakdown - **Data Collection:** 90/100. The data collection scope covers analytics, crash reporting, and marketing engagement; no behavioral advertising or data broker SDK integrations are present in this build. - **Data Sharing:** 95/100. Fraud device signals are routed through Navy Federal's own servers rather than sent directly to third-party risk services, and no data is shared with advertising networks. - **User Control:** 90/100. The app provides standard account management controls and supports data deletion requests, as disclosed in the Google Play data safety label. ## Positive Security Features - Authentication keys are stored in hardware-backed secure storage via the ForgeRock SDK - Device tamper detection blocks login on compromised devices - HTTPS is enforced globally across all banking traffic; the primary banking API applies strict server-side connection verification - App data is excluded from Android cloud backup and ADB backup, preventing account data exposure via backup channels - Fraud device signals route through Navy Federal's own infrastructure rather than going directly to third-party risk servers - No behavioral advertising SDKs are present; account and usage data is not shared with advertising networks ## Areas for Improvement ### Disclosure observations Observations about disclosure, each stated against the published guidance so a reader can compare: 1. **Analytics environment configuration in production** The Google Play data safety label (retrieved August 2026) states the app may share location, financial info, and contacts with third parties. The analyzed build's resource files configure Adobe Analytics using a development Launch environment identifier. Adobe's Experience Platform Launch documentation distinguishes development and production environments by their rule sets and report suites; whether production event data reaches the intended report suite under this configuration was not determinable from static analysis alone. 2. **Google Advertising ID linkage** The binary links Google's Advertising ID framework. Google Play policy guidance requires apps to disclose advertising ID use and to use it only for advertising or analytics purposes. No advertising SDK was identified in this build; the purpose of this linkage was not determinable from static analysis alone. ### Security Enhancements 1. **URL scheme navigation verification** AndroidManifest.xml registers 79 entries for the `mobile://navyfederal/` custom URI scheme without domain ownership verification enabled. Enabling Android App Links verification for these navigation paths, or restricting them to an allowlist of known safe destinations, would reduce the potential for co-installed apps to navigate to sensitive banking screens. 2. **Open banking callback verification** AndroidManifest.xml configures the Yodlee open banking callback activity with domain verification explicitly disabled. Enabling verification for this callback would allow Android to confirm that only the intended app can handle the authorization response from Yodlee. 3. **Production build hygiene** AndroidManifest.xml in this build declares four test and preview activity classes as externally accessible, and test framework files are included in the source tree alongside mock financial data in the assets directory. Separating development tooling from production builds would reduce the internal API schema information visible to anyone examining the APK. ## Technical Context **App Type:** Credit union mobile banking, high data sensitivity **Classes Analyzed:** 6,626 analyzed source files (protected by ProGuard obfuscation) **Third-Party Services:** 21 third-party integrations identified **Context Tags:** financial, sensitive_data, location, camera, advertising_id --- ## 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:** Navy Federal Credit Union **Version:** 2026.7.2 (versionCode 89382) **Analysis Date:** 2026-08-12 **Package:** com.navyfederal.android ### Analysis Limitations - Static analysis only (code review without running the app) - Based on APK version 2026.7.2 analyzed on 2026-08-12 - May not reflect server-side security controls - Cannot detect all runtime behaviors