Configuring Security Controls

Overview

Security controls are grouped into portal categories. Each control can be enabled or disabled by environment, and response controls can also define what happens when a protected app reports a security condition.

Treat configuration changes like release changes. Start with observation, validate on representative devices, then promote stricter responses only after your team understands the effect.

Control Areas

Prevention Controls

Prevention controls are active protections that block or harden specific behaviors. Most are simple on/off settings and are included in the next protected build that uses the selected environment.

See Prevention Controls Reference for detailed behavior, rollout, and platform guidance.

Detection And Response Controls

Detection controls identify security conditions at runtime. Each control uses one of the response actions described later in this guide.

Connection Controls

Connection controls are configured in Connection Settings. See Connection Settings for certificate management details.

Additional Features

Additional features are configured in Device Settings. See Device Settings for telemetry storage and live configuration behavior.

Code Obfuscation

Code obfuscation is applied during protected build creation. Available behavior depends on plan, platform, and selected obfuscation profile. See Code Obfuscation for the detailed options.

Response Actions

Response controls can use one of four actions. The portal labels are Log, Terminate, Message, and Redirect.

Log

The app continues running. When device logging is available and configured, the event can appear in Device Logs or dashboard views.

Use Log for first rollout, monitoring, false-positive review, and policy tuning.

Terminate

The app blocks continued use when the detection triggers. Use Terminate only for high-confidence conditions where the app must not continue.

For user-facing enforcement, prefer Message or Redirect when users need remediation guidance.

Message

The app displays an in-app message using configured text and button behavior. Use Message when users need context before access is limited.

Message configuration supports:

If a message button uses a redirect action, provide a corresponding redirect URL. Write custom messages in the languages your app supports, and test layout on small screens before Production rollout.

Message And Configuration Limits

Configuration limits are measured in UTF-8 bytes. For JSON configuration limits, the saved compact JSON payload counts, including field names, punctuation, and configured text.

If a configuration exceeds these limits, the portal rejects the save and shows an error before the change is used for a build or live configuration push.

Redirect

Redirect opens a specified URL and then blocks continued use according to platform behavior. Use it when the next step is outside the app, such as an app store page, support article, or compliance workflow.

Redirect configuration requires exactly one URL for the redirect action. The portal validates URL format before saving.

Configuring a Response Control

1. Select the correct tenant and environment.
2. Navigate to the appropriate control category in the sidebar.
3. Find the control you want to configure.
4. Toggle the control to Enabled.
5. Select the response action: Log, Terminate, Message, or Redirect.
6. If using Message, configure title, body, buttons, button actions, and any needed redirect URLs.
7. If using Redirect, enter the destination URL.
8. Select Save.
9. Protect and test a build before promoting the change.

Each response control card shows an enable switch, an action selector, action-specific configuration fields, and platform support details.

Saving And Applying Configuration

1. Make changes in the selected environment: Development, Staging, or Production.
2. Select Save to store the current state of controls, toggles, and response actions for that environment.
3. Build-time changes apply to the next protected build that uses the environment.
4. Supported live configuration changes can be pushed to already-deployed apps when the app was built with live configuration enabled.

Saving does not automatically promote changes to other environments.

Configuration Promotion

To promote a tested configuration from one environment to another:

1. Navigate to the source environment, such as Development.
2. Select Promote.
3. Promotion flow is Development -> Staging -> Production.
4. Confirm the promotion. The target environment's configuration is overwritten.

Promotion Best Practices

• Test in Development first, usually with Log responses.
• Promote to Staging and validate with QA or pilot devices.
• Promote to Production only after protected-app testing.
• Keep release notes with configuration changes and build job IDs.
• Use the Security Dashboard and Device Logs to monitor behavior after promotion.

Live Configuration Push (Enterprise)

Enterprise tenants can push supported configuration changes to already-deployed apps when live configuration was enabled before release:

1. Save the configuration in the desired environment.
2. Open Device Settings.
3. Select Push Latest Live Configuration.
4. Deployed apps receive the supported configuration update according to runtime behavior.

Build-time controls, structural changes, and many prevention settings still require a new protected build.