Intrusion Detection: How Veilo Catches Snoopers in the Act

Most privacy apps tell you what happened after the fact — a file was accessed, a sync occurred, a permission was granted. Very few tell you who tried to get into your most private data when you weren't looking. Intrusion detection in a mobile vault app flips that dynamic: instead of being reactive, it turns your vault into an active witness, silently recording every unauthorized access attempt with a timestamped front-camera photo. The result is a security feature that doesn't just protect your data — it documents the people who tried to breach it.

What Mobile Intrusion Detection Actually Is

In enterprise security, "intrusion detection system" (IDS) refers to network monitoring tools that identify anomalous traffic patterns indicative of an attack. In the context of a mobile photo vault, the term describes something more targeted and more personal: automated front-camera capture triggered by repeated failed unlock attempts.

The feature exists at the intersection of several capabilities that modern smartphones have offered for years — front-facing cameras with reliable auto-focus and low-light performance, fast local storage for silent image capture, and app-level access to camera APIs without requiring a visible shutter sound or camera UI. What vault apps do is combine these capabilities with a trigger: a threshold number of failed PIN entries or biometric failures that signals "this is probably not the legitimate user."

At its core, intrusion detection in Veilo does four things:

1. Monitors failed unlock attempts in real time
2. Silently activates the front camera after a configurable threshold
3. Captures a photo without any visual or auditory indication to the person holding the phone
4. Stores that photo — along with a precise timestamp and attempt count — inside the encrypted vault, invisible to anyone who doesn't have the real PIN

The person holding the phone sees what appears to be a normal failed unlock. They do not see a shutter animation, a camera preview, a flash, or any other indication that anything has been recorded. The capture is entirely silent and invisible.

The Technical Mechanics of Silent Capture

Understanding how silent capture is technically implemented helps explain both its reliability and its constraints.

Modern mobile operating systems provide camera APIs that allow apps to capture images programmatically — without launching the camera app, without displaying a viewfinder, and, on most Android devices, without triggering the system shutter sound (which, notably, cannot be suppressed on certain carrier-locked devices in Japan and South Korea for regulatory reasons, but is suppressible everywhere else). iOS also allows silent capture through AVCaptureSession, bypassing the system camera sound that only appears when using the native Camera app.

The implementation flow in a vault app looks roughly like this:

User enters incorrect PIN
      ↓
Failed attempt counter incremented (stored in encrypted local state)
      ↓
Counter reaches threshold (e.g., 3 failed attempts)
      ↓
App silently initializes AVCaptureSession (iOS) / Camera2 API (Android)
      ↓
Configures front camera: auto-exposure, auto-focus, no flash
      ↓
Captures still image — no UI, no sound, no notification
      ↓
Immediately terminates camera session
      ↓
Encrypts captured image with vault key
      ↓
Writes encrypted image + metadata (timestamp, attempt #) to intrusion log
      ↓
User sees: standard "Incorrect PIN" error message, nothing else

The key design requirement is that the camera session must be both fast and silent. Fast, because a delay between the failed PIN entry and the capture might mean the person has already moved or put down the phone. Silent, because any indication of capture defeats the entire purpose — the person would know they'd been photographed and might cover the camera or shield their face.

On iOS, AVCaptureSession with the .photo preset is the standard implementation path. The capture happens in a background thread with no impact on the main UI thread (which continues displaying the error state). On Android, the Camera2 API (CameraManager, CameraDevice, CameraCaptureSession) provides equivalent capability, and capturing without surfacing a SurfaceView to the user is straightforward with an ImageReader configured as the target surface.

Both platforms require camera permission to be granted — this is why a vault app requesting camera permission during onboarding is legitimate and expected. The permission is used for both the in-app secure camera (if present) and the intrusion detection capture. Apps that don't explain this upfront should be asked why they need camera access; apps like Veilo disclose it clearly.

What Gets Captured and Stored

Each intrusion event in Veilo's log contains:

• Front-camera photo: A full-resolution still image from the front camera at the moment of capture. Quality depends on ambient light and the device's front camera, but in typical indoor conditions the image is sufficient for identification.
• Timestamp: Precise to the second, recorded in UTC with local timezone offset. This matters if you're documenting an event for any formal purpose.
• Attempt number: Whether this was the 3rd, 4th, or 10th failed attempt. A pattern of multiple attempts over different time periods tells a different story than a cluster of attempts in one session.
• Device orientation: Landscape vs. portrait, which can help contextualize the image.

All of this is stored as an encrypted record inside the vault. It is not accessible through the decoy vault, it does not leave the device unless you explicitly export it, and it does not sync to any third-party service. The evidence exists only inside your real vault, readable only to someone who holds the real PIN.

This matters for a specific reason: the intrusion detection evidence itself would be sensitive in some contexts. You don't want a record of who tried to get into your vault to be accessible to… the person who tried to get into your vault. Storing it inside the encrypted space creates a clean security boundary.

Configuring Intrusion Detection Effectively

Most users should accept the defaults, but understanding the configuration options helps you tune the feature to your actual threat model.

Trigger Threshold

The threshold — how many failed attempts before capture triggers — involves a tradeoff. Too low (e.g., 1 failed attempt) and you'll capture yourself every time you mistype your PIN in dim light. Too high (e.g., 10 attempts) and a determined attacker with some knowledge of PIN formats might have worked through several candidates before being photographed.

Three to five failed attempts is a reasonable default for most people. If you have a consistent habit of mistyping your PIN, set it to four or five. If you live or work in a situation where targeted access attempts are a realistic risk, two or three makes more sense.

Multiple Captures per Event

Some vault apps capture only once at threshold; others capture at threshold and again on each subsequent failure. Multiple captures provide better coverage — if the first capture catches only a blurry partial face because the phone was in motion, the second or third attempt (by the attacker, captured automatically) may yield better results. Veilo captures on every failed attempt past the threshold, giving you a sequence rather than a single shot.

Auto-Lock Behavior

Intrusion detection works best when paired with aggressive auto-lock settings. If your vault stays unlocked in the background for 30 minutes, a window of physical opportunity exists that bypasses the detection entirely. Set the vault to lock immediately when backgrounded or after a very short idle period (30–60 seconds). This maximizes the number of scenarios where an attacker must go through the lock screen — which is where intrusion detection lives.

Pairing with the Decoy Vault

Intrusion detection and the decoy vault are designed to work in complementary fashion, covering different attack vectors. Understanding how they interact clarifies the full threat model they together address.

The decoy vault handles coercion: you're present, you're being pressured, and you open an alternative vault under duress. Intrusion detection handles opportunistic or targeted access: you're not present, someone has your physical phone and is attempting to bypass the lock.

The two scenarios are mutually exclusive at the moment of the attempt — but both can occur across the lifecycle of owning a device. You might be subject to an opportunistic unlock attempt when you leave your phone on a desk, and separately face a coerced unlock scenario at a checkpoint. Learn how the decoy vault handles coercion scenarios in detail.

When intrusion detection fires during an opportunistic attack, the attacker eventually gives up (or succeeds through the decoy vault if they somehow know it exists). You later open your real vault and see exactly who was trying — photo, timestamp, number of attempts. If the attacker used the decoy vault and was satisfied with it, you additionally have evidence of their face even though they technically "succeeded" in unlocking something.

Key takeaway: Intrusion detection turns every failed unlock attempt into documented evidence stored inside the one place the attacker couldn't reach. The asymmetry is deliberate — they exposed themselves trying to get to your private data, and the record of that exposure is protected by the same encryption they were trying to defeat.

Real-World Scenarios Where This Matters

The Borrowed Phone

A friend, family member, or colleague "just needs to make a call" and then spends more time on your phone than expected. When you later check your intrusion log, you see three failed attempts on the vault you didn't know they'd noticed, plus a clear face photo from your front camera. No confrontation needed — you have evidence and can decide how to use it.

The Stolen Phone

A thief who has taken your locked phone might attempt to access your vault as a secondary objective. The intrusion log captures their face and the exact time of each attempt. Combined with a police report about the theft, this provides investigators with a clear identification lead. Several users have documented phone thieves through exactly this mechanism.

The Overzealous Search

At a border crossing or during a stop-and-search scenario, an officer may attempt to access your vault independently. If the attempts fail (because they're guessing), you have a timestamped record — potentially useful for documenting the search for a journalist, lawyer, or human rights organization. See border crossing phone privacy for the broader context of preparing your device before travel.

The Domestic Surveillance Scenario

In situations involving a controlling partner who monitors phone usage, intrusion detection provides evidence of access attempts that the target can document and potentially use in legal proceedings. Combined with the decoy vault, it creates both protection and documentation — a combination that can be meaningful in the context of a protective order or custody dispute.

The Privacy of the Feature Itself

There is an important meta-question worth addressing: is it an invasion of privacy to photograph someone who is holding your phone without their knowledge?

The answer varies by jurisdiction and context, but the general principle is well-established: you do not have a reasonable expectation of privacy when you are physically holding someone else's property and actively attempting to access its contents without authorization. The person attempting the intrusion is the one who has violated a legal and social norm; photographing them in the act of doing so is broadly analogous to a security camera recording someone trying to break into a building.

That said, the feature should be used with some care. If you regularly lend your phone for legitimate purposes and don't want to photograph friends or colleagues who might curiously tap on the vault icon, set the trigger threshold higher. The configuration exists to let you calibrate the feature to your actual social context.

It is also worth noting that the captures never leave your device automatically. There is no server receiving these images, no notification sent to Veilo, no third party who can access them. They exist only inside your encrypted vault, under your control, for your use.

Why on-Device Storage of Evidence Matters

A design choice that might seem like a limitation — evidence stored on the device, not backed up to a server by default — is actually a deliberate security property.

If intrusion captures were automatically uploaded to a cloud service, several problems would emerge: the server could be subpoenaed or breached, the upload would require network access at capture time (not always available), and the very existence of a cloud record of who tried to access your vault could be exploited by an adversary. On-device storage keeps the evidence under the same encryption and access controls as everything else in the vault.

For users on Veilo's Pro Max plan, zero-knowledge encrypted cloud backup means that intrusion logs can be included in a secure backup — but the backup is encrypted with your key before it leaves the device, so the server stores only ciphertext. Even backed-up evidence remains inaccessible to anyone without your key. The Veilo Pro Max cloud backup article covers this architecture in detail.

Limitations and Honest Caveats

Camera angle: If the phone is face-down on a table, the front camera captures nothing useful. Intrusion detection is designed for a phone being held and interacted with, not for all physical positions.

Low light: Very dark environments will produce low-quality or unusable captures. This is a hardware limitation, not a software one — the front camera on any phone struggles with near-zero light.

Masked faces: Someone who knew about the feature and covered their face would defeat the identification purpose. The capture still happens and still logs the timestamp and attempt count, but identification from the image would be difficult.

Does not prevent access: Intrusion detection is a documentation tool, not a lock-out mechanism. It records who tried and, if they have your PIN (or correctly guess it), doesn't prevent access. It is most valuable when paired with a strong PIN and auto-lock settings that make unauthorized access difficult.

Frequently Asked Questions

Does intrusion detection require any special permissions?

Yes — camera permission is required. On both iOS and Android, Veilo requests camera access during onboarding and explains its dual purpose: the in-app secure camera for capturing photos directly into the vault, and intrusion detection. If you deny camera permission, intrusion detection will not function, but the rest of the vault operates normally.

Will the person being photographed see or hear anything?

No. The capture uses silent camera APIs that produce no shutter sound, no flash, and no visible camera UI. To the person holding the phone, it looks exactly like a normal failed PIN attempt with an error message.

Where exactly are the intrusion photos stored?

Inside your encrypted vault, in a dedicated intrusion log section accessible only through the real vault (not the decoy vault). They are not stored in your photo library, not uploaded to any server, and not accessible through the file system to other apps.

How do I view my intrusion log?

In Veilo, the intrusion log is accessible from the vault settings menu after unlocking with your real PIN. You'll see a chronological list of events with the front-camera capture, timestamp, and attempt count for each.

Can I export intrusion photos for use in a legal proceeding?

Yes. Individual captures can be exported from the intrusion log to a secure location. The exported image retains its original EXIF metadata including timestamp. Consult a lawyer about chain-of-custody requirements if you intend to use the images as formal evidence.

Does intrusion detection work when the phone is in airplane mode?

Yes. Capture, encryption, and storage all happen entirely on-device with no network dependency. Intrusion detection works regardless of connectivity status.

Conclusion

Intrusion detection is one of those features that feels like a nice-to-have right up until the moment you open your vault and find a photo of exactly the person you suspected — with a precise timestamp that confirms when it happened. At that point, it shifts from a marketing bullet point to a piece of actionable evidence.

The technical design is elegant in its simplicity: leverage the hardware capabilities every modern phone already has, trigger silently at a configurable threshold, and store the result inside the most protected space on the device. Combined with the decoy vault for coercion scenarios, it creates a physical security posture that covers both the opportunistic and the targeted attacker.

Veilo includes intrusion detection as part of its Pro tier — because genuine privacy in 2026 means knowing not just that your data is protected, but who tried to get to it and when.