Rihuum SecureTrack AI
Device and asset recovery begins with lawful enrolment.
SecureTrack is a requirements and architecture programme for verified owners and authorised organisations. It is designed around visible enrolment, minimum approved signals, accountable evidence and safe recovery.
This website has no public tracking, device telemetry, location search or remote-command capability.
Discuss requirements →- State
- Requirements and architecture
- Public tracking
- Not available
- Eligible assets
- Verified and enrolled
- Recovery model
- Human-controlled
01 / Product requirements
The conditions that must hold before capability.
Technical feasibility is subordinate to ownership, consent, platform policy, security, privacy and a safe incident response.
- Authority before enrolment
- The customer must own the asset, have voluntary consent or hold documented authority to manage it.
- Verified enrolment
- Every future device agent must be visibly installed, associated with an accountable owner and tested before an incident.
- Minimum approved signals
- Collection is limited by product edition, operating system, permission, purpose, retention and published policy.
- Evidence integrity
- Events require source, time, confidence, custody and access controls before use in an incident record.
- Human-authorised action
- High-impact controls may run only on eligible managed devices and only after explicit authority.
- Safe recovery
- The workflow supports account protection, evidence preservation and lawful escalation—not confrontation.
02 / Target architecture
Planned modules, not a deployment claim.
Every module requires its own threat model, platform compatibility, secure engineering, evaluation and release approval.
- SIM Shield
- Detect supported physical SIM, eSIM, slot, subscription or default-network changes where the platform lawfully exposes them.
- Mobile Agent
- A proposed visible enrolled Android agent for permitted check-in, integrity, location and security events.
- Computer Agent
- A later signed Windows, macOS or Linux agent for approved inventory, health and check-in signals.
- Asset Registry
- Registered devices and future approved Bluetooth, NFC, QR, UWB or cellular accessories.
- Recovery Intelligence
- Correlation of approved signals into human-reviewed recovery priorities after model and security evaluation.
- Evidence Vault
- A future controlled evidence service requiring stronger infrastructure, retention and access gates.
- Account Protection
- Guided incident communications and approved account-protection steps after workflow testing.
03 / Platform reality
One recovery promise cannot fit every operating system.
A released edition would publish a tested matrix by device, operating-system version, permission and management mode.
| Android | Primary mobile directionBackground access, location, managed actions and store policy require separate compatibility and release gates. |
|---|---|
| iPhone / iPad | Native preparedness firstConsumer recovery remains owner-controlled through Apple Find My. Future enterprise scope depends on supported supervised-device and MDM functions. |
| Windows | Proposed enrolled agentApproved check-in and security signals depend on management mode; universal continuous GPS or lost mode is not promised. |
| macOS / Linux | Later validated scopeCompatibility, signing, secure update, privacy and support matrices must be published before release. |
04 / Target recovery workflow
A controlled sequence from preparation to review.
Location or security signals, where lawful and available, support a safe response. They do not authorise vigilante recovery.
- Enrol
Verify authority, register the asset, record notice or consent and establish trusted recovery contacts.
- Prepare
Confirm permission, account security, encryption, backups, recovery channels and a test alert.
- Detect
Record only approved signals with their source and confidence.
- Protect
Guide data and account protection; limit any remote control to eligible authorised systems.
- Recover
Coordinate safe contact, evidence, insurer or law-enforcement engagement and approved recovery steps.
- Review
Close the incident, apply retention rules and improve future readiness.
Non-negotiable boundary
SecureTrack must never enable covert surveillance.
Product safety is defined as much by prohibited capability as by intended functionality.
- No secret tracking of arbitrary people, phones, computers or vehicles.
- No hidden microphone or camera activation, keylogging, credential theft or message interception.
- No guaranteed precision, recovery or persistence after every reset.
- No subscriber, telecom-tower or interception access without the operator and lawful authority.
- No public form that accepts an identifier and claims to locate a device.
05 / Product questions
Clear answers before promises.
All future capability remains subject to tested compatibility, lawful authority and release evidence.
01Can SecureTrack track any phone from its number or IMEI?
No. A phone number, IMEI, email address or IP address does not give Rihuum lawful or technical access to an arbitrary device.
02Will it always reveal a new number after a SIM change?
No. The number can be reported only when the operating system or network lawfully exposes it. Many devices and carriers do not provide it.
03Will it survive every uninstall or factory reset?
No product can honestly guarantee that on every consumer device. Eligibility depends on platform policy, management mode, permission, connectivity and whether the agent remains installed.
04Is there a public tracking service on this website?
No. This site collects no SecureTrack device telemetry, location or remote commands. The product remains at requirements and architecture stage.
Requirements research
Contribute a lawful device or asset use case.
Rihuum is evaluating needs, technical limits, privacy, security, support cost and measurable recovery value before any pilot commitment.