This guide explains how to allow applications in EPM macOS using an allowlist.
Access path
- On Segura® Platform, go to the Products menu and go to EPM > Policies > macOS > Access policies.
- Click Add and, in the Segregation screen, choose the scope: General, Device, or User.
General tab
- Fill in the fields:
- Category*: Applications.
- Name*: define a representative name (e.g., Allow
Xcode). - Status*: Active.
- Action*: Allowlist.
- Click Continue.
Applications tab
- (Optional) Record session for these applications*: Enabled/Disabled.
- In Strategy, choose how the criteria will be evaluated:
- Match any criteria: the policy will apply if any of the criteria are met.
- Match all criteria: the policy will apply only if all criteria are met.
- Add rules based on the following attributes:
- Application name: the name of the application you want to allow or block.
- Package identifier: the unique identifier of the application package.
- Code signature: the digital signature of the application, used to verify authenticity and integrity.
- Installation path: the full path in the file system to the application’s executable.
- Developer identity: the developer or organization that signed the application.
- Version: the specific version of the application you want to allow or block.
- SHA256 executable hash: SHA-256 hash of the executable, used to verify file integrity.
- SHA512 executable hash: SHA-512 hash of the executable, used to verify file integrity.
- Executable name: the name of the executable file; may optionally include arguments to target specific executions.
- Application category: the category/type of the app (e.g., Productivity, Games, Entertainment).
- User: the local account under which the application runs.
- Arguments: command-line parameters required or expected during the app execution.
Info
Use of regular expressions (Regex): for text-based criteria such as Installation path, Executable name, or Arguments, you can use regular expressions in the PCRE2 standard in the Rule field.
This allows creating flexible patterns to cover different application scenarios.
- Use the Add button to register each criterion individually.
- Click Continue.
Workflow tab
Workflow Settings section
- Require reason to execute applications: requires the user to provide a reason (logged for auditing).
- Require approval to elevate applications: requires prior approval. Configure:
- Approvals required.
- Disapprovals required to cancel.
- Approval levels: enables sequential workflow by levels.
Access request settings section
- Is it mandatory to provide a governance code when justifying? (Yes/No)
- Always add the user’s manager as an approver? (Yes/No): automatically includes the requester’s manager as an approver.
Review tab
- Review the summary of General, Applications, and Workflow.
- Click Save.