Q: Why does the TruU app request Location Services permission for Wi‑Fi environment scanning used in risk evaluation?
A: The TruU app uses Wi-Fi environment signals as one of the inputs for risk checks. When enabled, it reads only limited Wi-Fi network metadata such as:- Network name (SSID) and access point identifier (BSSID / Wi-Fi MAC address)
- Signal strength (RSSI), channel/frequency, link quality
- Network security protocol
- Network connection status
- Detect unusual or unfamiliar environments
- Contribute to risk assessments for access decisions
Q: What is a re-auth prompt and why does it happens?
A: It is a risk-driven security action based on the system’s real-time risk level. Note that number of re-auth prompts triggered per configured policy in admin console. It happens when current behavior-based risk crosses configured re-auth thresholds.
A: The system raises security posture and can require re-authentication according to configured policy.
Q: What is the reauth_prompt risk level in CAuth, and how is it computed from real-risk and confidence thresholds to trigger reauthentication-related actions?
A: When the user risk moves to high. TruU prompted to re-authenticate with valid pin or bio based on enrollment. This prevented using seamless SSO when their risk moves to high so that bad actors cannot perform actions on other user’s systems.
TruU observes the value for “real” risk. When the risk crosses the threshold per configured policy in admin console, the user is prompted to authenticate
- Face, if available
- Fingerprint, if available
- PIN
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\TruU\Authenticator
Key name: ReauthTimeoutSec Default: 30 seconds Effect: UiRestart required when changed
A: Yes. Risk is continuously reevaluated and may decrease as new trusted activity is observed.
Q: How often can prompts appear? What is the cool down period?
A: As a user, I don’t want to get prompted too often to re-authenticate so that if Cauth is making a mistake on determining my risk level I am not spammed with re-auth prompts. Customer configurable setting for a Cauth re-auth cooldown: AuthCooldownSeconds Default value is 30 minutes (1800 seconds) When a user is prompted for re-auth, the cooldown period starts. They are not prompted for re-auth again during the cooldown period even if the risk changes to a value that should trigger the prompt If the cooldown period passes and the risk is above the threshold, the user is immediately prompted WA does not wait for a risk change, but instead checks the current risk value when the period ends ChecklistQ: What does a Risk Change Event mean for a user session, and what triggers it?
A: Risk Change Events are generated when the system detects a change in the session’s re-authentication risk level (Real Risk).
Q: What if re-authentication prompt was correctly triggered by policy, but the prompt timed out because the user took no action?
A: If the re-auth prompt times out because the user takes no action, the behavior is expected:- Outcome is treated as
Timeout. - It records a failed auth event with message like “Re-authentication failed: timeout”.
- Then it calls to lock the machine.
Q: What happens if the user successfully verifies with a valid PIN or biometric after a policy-triggered re-authentication prompt?
A: When that happens, the flow is a successful re-authentication:
- Prompt is triggered because
RealRisk >= policy threshold. - User completes verification with valid PIN/BIO.
- Outcome is marked Success and a success auth event is recorded.
- A cooldown starts (
AuthCooldownSeconds) to suppress immediate repeat prompts. - Workstation is not locked.
Q: What happens when a user enters an incorrect PIN during re-authentication if they have biometrics enrolled?
A: After policy re-auth, a bad PIN uses up attempts and can lock PIN entry for a cooldown, but with biometrics enrolled the user is expected to finish using fingerprint or face during that time; only if biometrics don’t succeed does the session fail and the workstation may be locked.
Q: What does it indicate when a Continuous Authentication event is logged as Success with additional info ‘Re-authentication prompted due to high risk’?
A: This event is triggered at the moment the re-auth flow starts and the final outcome (success/timeout/cancel/error) is logged afterward as separate auth events
Q: What does the CAUTH_NO_KEYBOARD_MODEL_TRAINED event mean, and under what conditions is it generated?
This event means CAuth/TCAT was installed, but the keystroke model has not been trained/available yet. TCAT model status can be Learning, Trained, or Unavailable. Operationally, when the keyboard model is missing, the scoring pipeline can’t produce a keyboard-based risk output. So, the event is essentially telling you: keyboard-based continuous-auth risk is not yet usable; it will start contributing once the “keyboard model … is now available / trained” event fires.
Q: What does the CAUTH_KEYBOARD_MODEL_INITIAL_TRAIN event indicate, and what changes after it is generated?
Truu has finished training an updated keystroke behavior model (used for risk scoring during continuous authentication), and the system is now able to use that newly trained model for future authentication decisions.
Q: What is the local retention policy for Model Data in Windows?
Local data retention is enforced automatically by the endpoint DB cleaner using configured per-table policies (Over all 14-day default rule)Q: What is the role of the Archiver endpoint URL in the agent’s transmission of device-stored records to the cloud service?
A: The Archiver URL (Prod: https://arc.truu.ai) is the HTTPS endpoint where the TruU agent periodically uploads batched following records from the local database.- CAuth model performance metrics
- CAuth models themselves
- Risk scores
- All peripherals are attached to machines (mice, monitors, etc.)
- All raw mouse movement information
- Keyboard embeddings and typing metadata