Module 01 — Foundation
Authentication Profiles
in Delinea
Authentication Profiles define the multi-factor requirements users must satisfy across different scenarios: platform logins, secret access, privilege elevation, and granular policy enforcement. This guide walks through every aspect of creating and managing these profiles.
Login MFA
Require additional factors when users authenticate to the Delinea platform, ensuring only verified identities gain access.
Secret Access MFA
Enforce MFA at the point of secret retrieval — passwords, SSH keys, and credentials — independently of login policy.
Step-Up Privilege
Trigger additional authentication challenges when users request elevated or just-in-time privileged access.
Granular Access
Apply different authentication requirements per folder, secret, role, group, or IP range with fine-grained control.
What is an Authentication Profile?An Authentication Profile is a named, reusable policy object in Delinea Secret Server or Privilege Manager. Each profile defines which MFA methods are acceptable, how many factors are required, the challenge timeout, and bypass conditions. Profiles are then assigned to policies throughout the platform.
Where Profiles Are Applied
Auth Profile
→
Login Policy
→
Secret Policy
→
Privilege Policy
→
Enforced
Module 02 — Setup
Creating Auth Profiles
Authentication profiles are configured in Admin settings and serve as reusable templates. Follow this step-by-step process to create your first profile.
Navigate to Admin → Configuration → Authentication
From the Delinea Secret Server dashboard, expand the Admin menu in the top navigation bar. Select Configuration, then scroll to the Authentication section. Click Authentication Profiles.
Click "Create New" and name the profile
Select + Create Authentication Profile. Give the profile a clear, descriptive name following your naming convention — e.g.
MFA-SecretAccess-HighPriv. Optionally add a description explaining its use case.Configure MFA methods and requirements
Select which authentication methods are allowed (TOTP, FIDO2, push notification, SMS, email OTP, or RADIUS). Set the minimum number of required factors. Enable or disable "remember device" and define the cache duration.
Set timeout and bypass options
Define how long a completed MFA challenge remains valid (default 30 minutes). Configure any allowed bypass conditions — such as trusted IP ranges or service accounts — carefully to avoid weakening the profile.
Save and assign
Click Save. The profile is now available to be assigned to login policies, secret policies, and privilege escalation rules throughout the platform.
Interactive: Build a Profile
New Authentication Profile
Allow Device Remember
Users can mark a device as trusted for the cache duration
Bypass for Service Accounts
Non-interactive accounts skip the MFA challenge
Require on Every Access
Disregards cache; challenge is triggered on each request
Profile Preview
# Authentication Profile Configuration
name: "Unnamed Profile"
min_factors: 2
primary_method: "TOTP"
challenge_cache_min: 30
allow_device_remember: false
bypass_service_accounts: false
require_on_every_access: false
name: "Unnamed Profile"
min_factors: 2
primary_method: "TOTP"
challenge_cache_min: 30
allow_device_remember: false
bypass_service_accounts: false
require_on_every_access: false
Naming Conventions MatterUse a consistent naming scheme across profiles — prefix with the use case (e.g. LOGIN-, PRIV-). This makes policy assignment and auditing significantly easier as your environment grows.
SECRET-, Module 03 — Login Security
MFA Requirements
for Logins
Attaching an authentication profile to the login policy ensures users must pass an MFA challenge before reaching the Delinea dashboard. This protects against credential compromise.
Go to Admin → Users → Login Policy
Navigate to Admin → Users → User Policies. Select the default policy or create a new one targeting a specific user group or role.
Assign an Authentication Profile
Under the Multi-Factor Authentication section of the policy, click Assign Profile. Select your pre-created authentication profile from the dropdown. Profiles you created are listed by name.
Configure scope
Choose whether this MFA requirement applies to all login types (web UI, API, mobile) or specific ones. For most environments, enforcing on all access methods is recommended.
Test with a pilot user
Before broad rollout, assign the policy to a test user account and verify the MFA prompt appears correctly at login, challenges complete, and sessions begin properly after successful authentication.
| Method | Security Level | User Experience | Best For |
|---|---|---|---|
| FIDO2 / WebAuthn | Highest | Hardware key tap or biometric | Privileged admins, PAM access |
| TOTP App | High | Enter 6-digit code from app | Standard enterprise MFA |
| Push Notification | High | Approve/deny on mobile | Fast, mobile-friendly logins |
| RADIUS | Medium | Delegates to RADIUS server | Legacy infra integration |
| Email OTP | Medium | Code sent to email | Low-risk accounts, fallback |
| SMS OTP | Lower | Code via text message | Last resort / legacy only |
SMS Security AdvisorySMS OTP is vulnerable to SIM-swapping and SS7 interception. Avoid for privileged accounts. Use FIDO2 or TOTP as the primary method for all high-value logins.
The authentication flow when a Login MFA policy is attached:
User enters credentials
Username + Password submitted
↓
Credential validation
AD/LDAP or local auth check
↓
MFA challenge triggered
Profile determines method + factors
↓
Cache check
Valid recent challenge? Skip or require
↓
Session granted
User reaches Delinea dashboard
Conditional BypassYou can configure IP range exceptions in the profile to skip MFA for users on trusted corporate networks, while still enforcing it for remote access. Navigate to the profile's Bypass Conditions tab and add CIDR ranges.
Module 04 — Secret Vault
MFA for Secret Access
Separate from login MFA, you can require an additional authentication challenge specifically when a user retrieves a secret — a credential, API key, or certificate. This adds a second layer of friction at the most sensitive operation.
Why separate Secret Access MFA?A user may be legitimately logged in but an attacker hijacks their session. Requiring MFA at secret retrieval means the attacker would need to also control the user's second factor at that moment — significantly harder.
Open a Secret Policy (or create one)
Navigate to Admin → Secret Policy. Either edit an existing policy or click + New Secret Policy. Secret Policies control what happens when a user interacts with secrets — including view, edit, checkout, and heartbeat.
Locate "Require MFA for Secret Access"
In the policy editor, scroll to the Security section. Find the setting Require MFA on Secret View. Toggle it on and select your authentication profile from the dropdown.
Set MFA trigger granularity
Choose whether MFA triggers on every view, once per session, or after a configurable timer. For high-value secrets (root credentials, production keys), always use every view.
Assign the policy to folders or secrets
Navigate to the folder or individual secret, open Policy, and select your new secret policy. Inherited policies apply to all child secrets unless overridden at the individual level.
Secret Policy MFA Matrix
| Secret Type | Recommended Trigger | Suggested Profile | Cache Duration |
|---|---|---|---|
| 🔴 Root / Domain Admin | Every View | FIDO2 + TOTP | None (0 min) |
| 🟠 Service Account Creds | Every Session | TOTP or Push | 30 minutes |
| 🟡 Database Passwords | Every Session | TOTP or Push | 30 minutes |
| 🟢 Application API Keys | Timer-based | TOTP | 1 hour |
| ⚪ Personal Dev Creds | Once Per Session | Push or Email | 8 hours |
API — Assign Auth Profile to Secret Policy
# Assign an auth profile to a secret policy via REST API
PATCH /api/v1/secret-policy/{policyId}
Content-Type: application/json
Authorization: Bearer {access_token}
{
"secretPolicyItems": [
{
"secretPolicyItemType": "MfaForView",
"enabled": true,
"authProfileId": 42,
"triggerType": "EveryView"
}
]
}
Module 05 — Elevation
Step-Up Privilege
Elevation
Step-up authentication is triggered when a user requests elevated privileges — for example, launching a privileged session, checking out a high-risk secret, or activating just-in-time access. A re-authentication challenge confirms intent and identity.
Create a "High Privilege" authentication profile
Create a dedicated profile for step-up scenarios with stricter settings — higher factor count, no device caching, and FIDO2 or TOTP as required methods. Name it clearly, e.g.
PRIV-StepUp-Strict.Go to Privilege Manager → Policy → Step-Up Rules
In Privilege Manager, navigate to Policy → Application Policies or Elevation Rules. Open or create the rule that governs when elevation is triggered for the target application or command.
Assign the authentication profile to the elevation action
In the elevation rule, under Authentication, select Require MFA Before Elevation and pick your step-up profile. This ensures users must re-verify every time they request privilege, regardless of login MFA state.
Define elevation duration
Set how long elevated access persists after a successful step-up challenge. For sensitive systems, use short durations (5–15 minutes). For DevOps workflows, 30–60 minutes may be acceptable with strong MFA.
Common scenarios where step-up MFA is triggered:
Privileged Session Launch
RDP, SSH, or database sessions to production servers require step-up before the session proxy connects.
Secret Checkout
Checking out an exclusive credential (so no one else can use it) triggers re-authentication at checkout time.
Run-as / sudo Elevation
Privilege Manager intercepts elevation requests on endpoints and challenges the user in place.
Approval Workflows
Combined with approval workflows — MFA after approval is granted, ensuring the correct person acts on the ticket.
Just-In-Time (JIT) privilege grants temporary, time-bound access. Here's the full flow with step-up MFA:
User requests JIT access
Ticket created in approval workflow
↓
Approver reviews & grants
Access is approved for N minutes
↓
Step-up MFA triggered
PRIV profile challenges the user
↓
Privilege activated
Time-limited, audited access begins
↓
Timer expires → revoked
Access automatically removed, session terminated
Combine JIT + Session RecordingFor the highest security posture, pair JIT access with session recording. Any privileged session initiated through this flow will be recorded and tied to the MFA event and approval ticket — creating a complete audit trail.
Module 06 — Fine Control
Granular Access
Control
Authentication profiles can be applied at extremely fine-grained levels — per folder, per secret, per role, per IP range, or per time window. This allows you to build layered, adaptive security policies tailored to your risk profile.
Dimensions of Granularity
By Folder / Secret
Each folder or individual secret can inherit or override its parent's auth policy. Production secrets get stricter profiles than dev.
By Role / Group
Assign different auth profiles to different AD groups — contractors might need TOTP, while sysadmins require FIDO2.
By IP / Network
Require stronger MFA from external IPs, while trusting internal CIDRs with lighter requirements (or none at all).
By Time Window
Apply stricter auth profiles outside business hours — even the same account faces stronger challenges at 2am on a weekend.
Interactive: Granular Policy Builder
Granular Policy Simulator
Select conditions to see which authentication profile would apply:
Computed Auth Profile
Select options above
Inheritance Model
Delinea uses a policy inheritance model. Profiles cascade from global → folder → secret, with child objects able to inherit, override, or block inheritance from their parent.
Inheritance Chain Example
# Policy inheritance example (top-down)
Global Policy: "LOGIN-Standard" ← applies to all users at login
└─ Folder: /Production
override → "SECRET-HighPriv" ← all secrets in Prod folder
└─ Secret: prod-db-root
override → "SECRET-RootCreds" ← stricter for this specific secret
└─ Folder: /Development
inherit → "LOGIN-Standard" ← inherits global, less strict
└─ Secret: dev-api-key
inherit → "LOGIN-Standard" ← inherits folder policy
Pre-Rollout Checklist
- ✓Inventory all existing secrets and categorize by risk level
- ✓Create at minimum 3 profiles: Low, Medium, High security tiers
- ✓Map AD groups to appropriate authentication profiles
- ✓Define IP ranges for trusted networks and configure bypass conditions
- ✓Test all profiles with pilot users before broad enforcement
- ✓Document the inheritance model and naming convention in your runbook
- ✓Set up alerting for MFA failures exceeding threshold
- ✓Schedule quarterly review of all authentication profile assignments
Module 07 — Assessment
Knowledge Check
Test your understanding of Delinea authentication profiles. Select the best answer for each question.
1. What is the primary purpose of creating separate Authentication Profiles for Login vs. Secret Access?
2. Which MFA method provides the HIGHEST security for privileged account logins?
3. In the policy inheritance model, if a secret inside a folder has no explicitly assigned policy, what happens?
4. Step-up MFA for privilege elevation is triggered BEFORE which action?
5. Which cache duration setting provides the strictest access control for root / domain admin credentials?