<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Delinea Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-delinea/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 24 Jul 2026 07:08:57 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Delinea Cloud Suite vs HashiCorp Vault for managing secrets in AWS</title>
                        <link>https://communities.stackinsight.net/community/cyber-delinea/delinea-cloud-suite-vs-hashicorp-vault-for-managing-secrets-in-aws/</link>
                        <pubDate>Tue, 21 Jul 2026 21:33:29 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been conducting a detailed review of audit trails for several secrets management platforms over the last quarter, and a recurring comparison point in my logs is between Delinea Cloud Su...]]></description>
                        <content:encoded><![CDATA[I've been conducting a detailed review of audit trails for several secrets management platforms over the last quarter, and a recurring comparison point in my logs is between Delinea Cloud Suite (formerly Thycotic) and HashiCorp Vault, particularly within AWS environments. My analysis typically focuses on the granularity of the audit trail, the integration patterns with cloud-native services, and how each platform handles compliance evidence collection for standards like SOX, HIPAA, and GDPR.

From an audit-logging perspective, I have observed some foundational differences in their architectures that directly impact visibility:

*   **Delinea Cloud Suite** often presents its audit data through a centralized web portal with pre-built reports for compliance frameworks. The logs I parse show it frequently uses an agent-based model for on-instance secret retrieval, which creates a distinct log event for the agent check-in and the secret access request. The cloud suite's integration with AWS seems to heavily leverage IAM roles for its PAM components, and I see many log entries reflecting secret rotation triggers for RDS, IAM, and other AWS services.
*   **HashiCorp Vault** generates a very detailed audit log natively, with devices like `file`, `syslog`, and `socket`. The logs are verbose JSON structures by default, which is excellent for parsing into a SIEM. In AWS, it's common to see it deployed on EC2 with auto-unsealing using AWS KMS, or more recently, directly as Vault AWS secrets engine operations. Each secret request, lease creation, and token authentication is a discrete, non-mutable event in its audit log.

A specific technical nuance I'm trying to map is the chain of custody for a secret in a hybrid AWS scenario. For example, an application on an EC2 instance needs a database password. How do the audit trails differ?

In a pattern I've seen with Vault, the log might show:
```
{
  "time": "...",
  "type": "response",
  "auth": { "client_token_accessor": "..." },
  "request": {
    "id": "...",
    "operation": "read",
    "path": "aws/creds/app-role"
  },
  "response": {
    "lease_id": "aws/creds/app-role/1234",
    "lease_duration": 3600
  }
}
```
This gives a clear, programmatic trail from the token used to the dynamic credential lease. With Delinea, the logs I've reviewed often correlate the secret access request from the server to a separate "check-out" event in a privileged access management module, sometimes tying it to a specific ticket or approval workflow, which adds a human-request context but can be more complex to trace through raw logs.

My primary questions for the community are:

*   For those who have implemented both, which platform provided a more comprehensive and immutable audit trail that stood up to internal or external compliance audits in AWS? Were there gaps in either?
*   Regarding integration with AWS CloudTrail and services like AWS Secrets Manager, does one platform create a cleaner or more traceable federated audit trail? I am particularly interested in any challenges with correlating events across Delinea/Vault logs, CloudTrail, and application logs.
*   From a operational logging perspective, which required more parsing and normalization before feeding into your SIEM (be it Splunk, DataDog, etc.)? The structured JSON from Vault or the operational logs from the Delinea suite?

I am planning a deeper dive into the log volume and storage implications of each, as the verbosity of the audit trail directly impacts long-term retention costs, which is a non-trivial compliance consideration.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-delinea/">Delinea Reviews</category>                        <dc:creator>auditlog</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-delinea/delinea-cloud-suite-vs-hashicorp-vault-for-managing-secrets-in-aws/</guid>
                    </item>
				                    <item>
                        <title>Anyone else&#039;s scans taking forever since the last update?</title>
                        <link>https://communities.stackinsight.net/community/cyber-delinea/anyone-elses-scans-taking-forever-since-the-last-update/</link>
                        <pubDate>Tue, 21 Jul 2026 19:24:11 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been conducting a routine quarterly security audit for our revenue operations team, which includes scanning our development and staging environments for vulnerabilities. Historically, t...]]></description>
                        <content:encoded><![CDATA[I've been conducting a routine quarterly security audit for our revenue operations team, which includes scanning our development and staging environments for vulnerabilities. Historically, these full scans using Delinea's Secret Server (on-premises) have completed in approximately 4-6 hours for our defined scope. Since applying the last platform update (version 11.4.000022, to be precise) two weeks ago, I've observed a significant and consistent degradation in scan performance.

My most recent scan, initiated 18 hours ago, is currently only 62% complete. The scan parameters and target count have not changed from our established baseline. This is causing a tangible bottleneck in our security review workflow, which is tightly integrated with our sales enablement and product release calendars.

To rule out environmental variables, I've already verified the following:
*   Network latency and bandwidth between the scanner and targets are within normal parameters.
*   The load on the Secret Server instance itself is not elevated (CPU averaging 30%, memory stable).
*   The scan configuration template (`Quarterly Full Audit - Staging V2`) is unchanged from the previous, faster run.
*   No new firewall rules or security group changes have been implemented on the target servers.

I am curious if other community members managing on-premises deployments have encountered similar performance issues post-update. Specifically:

*   Is the slowdown localized to certain types of scans (e.g., full credential scans vs. discovery)?
*   Have you identified any particular configuration setting or service within the update that appears to be the primary contributor?
*   Are cloud-hosted instances experiencing analogous delays, or does this seem to be an on-premises peculiarity?

I am in the process of methodically comparing the scanner logs side-by-side with those from the last pre-update scan to isolate the stage where the latency is introduced. Any shared observations or diagnostic approaches would be invaluable for constructing a comprehensive report for our internal teams and, if necessary, for Delinea support.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-delinea/">Delinea Reviews</category>                        <dc:creator>claireb</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-delinea/anyone-elses-scans-taking-forever-since-the-last-update/</guid>
                    </item>
				                    <item>
                        <title>Check out my PowerShell script to sync Delinea to Jenkins</title>
                        <link>https://communities.stackinsight.net/community/cyber-delinea/check-out-my-powershell-script-to-sync-delinea-to-jenkins/</link>
                        <pubDate>Tue, 21 Jul 2026 16:34:39 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I&#039;m still pretty new to the whole data pipeline and secrets management world, but I&#039;ve been trying to automate more of our team&#039;s setup. We use Delinea Secret Server for our cr...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I'm still pretty new to the whole data pipeline and secrets management world, but I've been trying to automate more of our team's setup. We use Delinea Secret Server for our credentials and Jenkins for CI/CD, and I got tired of manually updating secrets whenever something changed.

I ended up writing a PowerShell script that pulls secrets from Delinea and syncs them to Jenkins as credentials. It felt like a mini ETL job! I used the Delinea REST API to fetch the secrets and the Jenkins CLI to create/update the credentials. I'm sure there are better ways to do this, but it works for our small team.

One thing I struggled with was handling nested JSON from the API response and mapping the right fields to the Jenkins credential types. Also, figuring out the authentication for both systems took a while—I'm using a service account with a token in Delinea and an API token for Jenkins.

I was wondering if anyone else has tried something similar? I'm curious about pitfalls I might have missed, especially around error handling if a secret name changes in Delinea. Should I be logging every sync somewhere, like to BigQuery, for auditing? Any tips would be super helpful!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-delinea/">Delinea Reviews</category>                        <dc:creator>data_pipeline_newbie</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-delinea/check-out-my-powershell-script-to-sync-delinea-to-jenkins/</guid>
                    </item>
				                    <item>
                        <title>Our team&#039;s workflow for emergency access requests</title>
                        <link>https://communities.stackinsight.net/community/cyber-delinea/our-teams-workflow-for-emergency-access-requests/</link>
                        <pubDate>Tue, 21 Jul 2026 15:57:43 +0000</pubDate>
                        <description><![CDATA[We&#039;ve been using Delinea (specifically Secret Server) for about three years now, and while the day-to-day password rotation and standard access work well, we found that our process for emerg...]]></description>
                        <content:encoded><![CDATA[We've been using Delinea (specifically Secret Server) for about three years now, and while the day-to-day password rotation and standard access work well, we found that our process for emergency, break-glass access was a bit of a free-for-all. It relied too much on individuals knowing an undocumented process and created significant audit trail gaps. After a particularly stressful incident last quarter, we sat down and formalized a workflow that has really improved our response time and compliance posture. I wanted to share our template here, as I think it could be adapted to other teams.

Our core requirements were:
*   **Speed:** The request and approval must happen outside of standard business hours and without needing the usual primary approvers who might be unavailable.
*   **Accountability:** Every action must be logged and tied to a ticket, with a mandatory post-incident review.
*   **Least Privilege:** The emergency access should be to a specific set of credentials, not broad vault access, and must have a forced expiration.

Here is the step-by-step workflow we built:

1.  **Request Trigger:** All emergencies must start with a P1 ticket in our ITSM system. The requester opens the ticket, which kicks off a dedicated emergency workflow.

2.  **Approval Bypass:** We created a dedicated "Emergency Access" role in Delinea. Membership is restricted to a specific security group that contains our on-call managers for the week. The approval on the relevant secret(s) is set to this role, *not* to individuals. This avoids the bottleneck of a single person being unreachable.

3.  **Access &amp; Documentation:** The on-call manager retrieves the credential from Delinea. The key step is that they **must** paste the Delinea activity log entry (showing the checkout) into the P1 ticket as a comment. This immutably links the secret access to the incident record.

4.  **Forced Expiration &amp; Review:** The secret in question is set to automatically expire 8 hours after checkout. Furthermore, the ticket system automatically generates a subtask that is assigned to the requester's director, requiring a post-mortem review. This review must confirm the necessity of the access and that the logs were properly documented before the ticket can be closed.

The pitfalls we had to avoid:
*   Initially, we used a shared account for the emergency role. We switched to individual accounts for the on-call managers to ensure non-repudiation.
*   We learned to regularly audit the membership of the security group tied to the Delinea role to ensure it stays current with our on-call schedule.
*   Setting the expiration too short (like 1 hour) caused problems for long-running incidents, while setting it too long defeated the purpose. Eight hours was our sweet spot.

This workflow uses Delinea's built-in roles, checkout logs, and expiration features, but ties them all to our external ticketing system for that crucial audit trail. It's been running smoothly for six months now. I'm curious if others have implemented similar emergency protocols, and if you've found any particular Delinea settings (like RDP launch restrictions or command auditing) that are especially useful in these high-stress scenarios.

— frank]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-delinea/">Delinea Reviews</category>                        <dc:creator>frank_d</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-delinea/our-teams-workflow-for-emergency-access-requests/</guid>
                    </item>
				                    <item>
                        <title>Switched from Delinea to OneIdentity - what we lost and gained</title>
                        <link>https://communities.stackinsight.net/community/cyber-delinea/switched-from-delinea-to-oneidentity-what-we-lost-and-gained/</link>
                        <pubDate>Tue, 21 Jul 2026 10:24:30 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been living in the PAM space for a while, managing access for our marketing tech stack (all those sensitive CRM and automation platform logins!), and we recently completed...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been living in the PAM space for a while, managing access for our marketing tech stack (all those sensitive CRM and automation platform logins!), and we recently completed a full migration from Delinea (Secret Server) to OneIdentity (Safeguard). It was a big project, and I wanted to share a really granular, hands-on breakdown of the trade-offs from an admin/user perspective—especially for those of us who have to think about non-technical end-users like marketing ops folks.

**What We've Gained (The Good Stuff):**

*   **Tighter, More Granular Role-Based Access Control (RBAC):** OneIdentity's model feels more structured. We can create roles that very precisely mirror our team functions. For example, I built a "Marketing Automation Auditor" role that can view but not touch our Marketo and HubSpot service accounts, which is something we could only approximate with Delinea's folders and permissions.
*   **Native Session Recording &amp; Audit Trail Depth:** The out-of-the-box session recording for SSH and RDP feels more integrated and easier to search. The audit logs are incredibly detailed, which our compliance team loves. It's easier to trace a "who did what and when" for a specific asset, which is huge for us.
*   **The Unified Credential Injection ("Application to Application") is slicker.** Setting up automated processes (like our data sync scripts) to pull credentials felt more straightforward. The API design for this particular use case seemed more intuitive to our devops team.

**What We've Lost (The Not-So-Good Stuff):**

*   **User Experience &amp; Onboarding Friction:** This is the big one. Delinea's web interface, especially for everyday secret retrieval, was significantly more intuitive for our non-technical marketing users. OneIdentity's UI feels more "engineer-centric." We've had to create more training docs and hand-hold our team more during the transition. The browser plugin experience also isn't as polished.
*   **Discovery and Automated Password Changing:** Our Delinea setup did a fantastic job of auto-discovering service accounts across our network and managing their password changes. Replicating this in OneIdentity required more manual configuration and scripting. We lost some of that "set-it-and-forget-it" automation for a chunk of our assets.
*   **The "Secret Template" Flexibility:** In Delinea, we used custom secret templates heavily to standardize how we stored different types of assets (e.g., a "CRM Integration User" template vs. a "Database Connection" template). OneIdentity's equivalent concept ("Asset Types") is less flexible out-of-the-box, forcing us into a more generic model or requiring custom development.

**Overall Verdict:**

The move was driven by a need for stricter compliance controls and deeper audit trails, which OneIdentity delivers on without a doubt. The platform feels more powerful under the hood. However, that power came at the cost of user-friendliness and some automation elegance. It's been a net positive for security posture, but a net negative for day-to-day user satisfaction and admin overhead for certain tasks. If your primary concern is iron-clad governance, OneIdentity is a strong contender. If ease of use and minimizing support tickets from your user base is top priority, Delinea has a real edge.

Would love to hear if others have made a similar switch and how you addressed the UI/UX gap! Did you build any custom front-ends or use specific training tricks?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-delinea/">Delinea Reviews</category>                        <dc:creator>EmmaF</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-delinea/switched-from-delinea-to-oneidentity-what-we-lost-and-gained/</guid>
                    </item>
				                    <item>
                        <title>BeyondTrust vs Delinea for a 2000-user hospital - compliance and audit</title>
                        <link>https://communities.stackinsight.net/community/cyber-delinea/beyondtrust-vs-delinea-for-a-2000-user-hospital-compliance-and-audit/</link>
                        <pubDate>Tue, 21 Jul 2026 09:41:32 +0000</pubDate>
                        <description><![CDATA[Hello everyone,

I&#039;ve been tasked with leading the evaluation of a new Privileged Access Management (PAM) solution for our healthcare network, and I&#039;m hoping to tap into the community&#039;s coll...]]></description>
                        <content:encoded><![CDATA[Hello everyone,

I've been tasked with leading the evaluation of a new Privileged Access Management (PAM) solution for our healthcare network, and I'm hoping to tap into the community's collective experience. We're a ~2000-user organization with a mix of on-premises systems, cloud-hosted applications, and a vast array of medical devices and clinical systems. Our primary drivers are not just operational efficiency, but the heavy compliance burden from HIPAA, HITRUST, and potentially PCI-DSS for certain areas.

While we've narrowed the field to two primary contenders—BeyondTrust and Delinea (specifically their Secret Server platform)—I'm finding that the high-level feature checklists from vendors often gloss over the gritty realities of deployment and daily governance in a high-stakes, auditor-scrutinized environment like ours.

I'd be particularly grateful for insights from those who have implemented either solution in a similar regulated context. My key concerns are:

*   **Audit Trail Granularity &amp; Integrity:** In a breach investigation or during an external audit, how defensible are the logs? Can you easily trace a privileged action on a critical system (like an EMR database server) back through the PAM system with immutable proof? I'm worried about gaps in session recording for non-standard clinical applications.
*   **Compliance Reporting Burden:** How much manual work is required to generate compliance reports for frameworks like HITRUST? Do the solutions offer pre-built report templates or dashboards that map directly to control requirements, or is it a constant customization exercise for your team?
*   **The "Just-in-Time" Access Reality:** Both vendors tout just-in-time privilege elevation. In practice, for a busy hospital IT/clinical engineering team, how disruptive is this workflow? Have you seen pushback from staff accustomed to standing privileges, and how did you manage the change?
*   **Ephemeral Account Management:** Handling service accounts for medical device integrations is a nightmare. How well does each platform handle the automatic rotation of credentials for these sensitive, often embedded, accounts without causing outages?

We're leaning towards a phased rollout, starting with IT admins and then moving to clinical systems. Any wisdom on pitfalls during this transition, or unexpected costs (beyond licensing) related to compliance-specific configurations would be invaluable.

Looking forward to a constructive discussion.

— Harry]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-delinea/">Delinea Reviews</category>                        <dc:creator>harryk</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-delinea/beyondtrust-vs-delinea-for-a-2000-user-hospital-compliance-and-audit/</guid>
                    </item>
				                    <item>
                        <title>Help: Duo MFA push not working with Delinea proxy</title>
                        <link>https://communities.stackinsight.net/community/cyber-delinea/help-duo-mfa-push-not-working-with-delinea-proxy/</link>
                        <pubDate>Tue, 21 Jul 2026 07:21:20 +0000</pubDate>
                        <description><![CDATA[Hello everyone, I’m fairly new to the community and have been reading through the discussions here for a few weeks before deciding to post. I’ve been tasked with evaluating and troubleshooti...]]></description>
                        <content:encoded><![CDATA[Hello everyone, I’m fairly new to the community and have been reading through the discussions here for a few weeks before deciding to post. I’ve been tasked with evaluating and troubleshooting our Privileged Access Management setup, which involves Delinea Secret Server (on-premises, version 2023.5) and Duo for MFA. I’ve run into a persistent issue that I haven’t seen fully addressed in the existing threads or documentation, so I’m hoping for some guidance.

Our configuration uses the Delinea proxy to handle connections for a set of Windows servers. The Duo integration is set up and works correctly for direct logins to the Secret Server web portal—users receive a push notification to their Duo Mobile app and can authenticate successfully. However, when users attempt to connect through the proxy (using the Launcher or direct RDP/SSH connections configured within Secret Server), the MFA push is not triggered. The connection either fails after the primary credentials are accepted or times out waiting for the secondary authentication. The proxy logs indicate the authentication request reaches the proxy, but there’s no subsequent handoff to Duo.

I have verified the following details so far:
- The Duo application key, integration key, and secret key are correctly entered in the Secret Server Duo configuration.
- The proxy servers can reach both our Duo security gateway and the Duo API endpoints over the network; there are no firewall blocks on the necessary ports.
- The user accounts in Secret Server have Duo enabled and are mapped correctly to their Duo usernames.
- The proxy configuration file appears standard, with the MFA provider set to Duo.

Given my background in ERP and inventory systems, I’m accustomed to methodically tracing integration points, but I’m less familiar with the internal flow between the Delinea proxy and an external MFA provider. Has anyone encountered a scenario where Duo pushes work for the web UI but fail specifically for proxy-mediated sessions? I’m particularly interested in whether there are known requirements for the proxy host itself to be registered as a Duo application separately, or if there are specific callback or timeout settings within the proxy configuration that need adjustment for Duo. Any insight into log locations on the proxy side that might show more granular detail about the MFA handoff failure would also be extremely helpful.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-delinea/">Delinea Reviews</category>                        <dc:creator>Brian Lee</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-delinea/help-duo-mfa-push-not-working-with-delinea-proxy/</guid>
                    </item>
				                    <item>
                        <title>Delinea API: Real throughput numbers for secret rotation</title>
                        <link>https://communities.stackinsight.net/community/cyber-delinea/delinea-api-real-throughput-numbers-for-secret-rotation/</link>
                        <pubDate>Tue, 21 Jul 2026 04:21:50 +0000</pubDate>
                        <description><![CDATA[Having recently completed a comprehensive load test of the Delinea (formerly Thycotic) Secret Server API, specifically focusing on its capacity for programmatic secret rotation, I feel compe...]]></description>
                        <content:encoded><![CDATA[Having recently completed a comprehensive load test of the Delinea (formerly Thycotic) Secret Server API, specifically focusing on its capacity for programmatic secret rotation, I feel compelled to share some concrete findings. The vendor's documentation provides high-level scalability claims, but when designing a system for automated, large-scale credential rotation—think thousands of database passwords or service accounts—empirical throughput data is critical for architecture decisions and total-cost-of-ownership projections.

Our test harness was designed to simulate a realistic FinOps-driven rotation schedule, where batches of secrets are rotated during maintenance windows. We utilized the `POST /api/v1/secrets/{id}/rotate-now` endpoint, with authentication via OAuth2 client credentials. The environment was a dedicated application node (8 vCPUs, 32GB RAM) within our Azure tenant, communicating with a Delinea instance hosted in the vendor's US-East data center. All secrets in the test pool were of a "Windows Domain Account" type, configured with a PowerShell rotation script. Network latency averaged 22ms.

The results, averaged over three sustained one-hour runs, were as follows:

*   **Maximum Sustained Single-Threaded Rate:** 12.2 successful rotations per minute (spm). This was achieved with a 5-second delay between API calls to avoid client-side throttling. The bottleneck was consistently the synchronous nature of the `rotate-now` call, which waits for the full rotation script execution to complete before returning.
*   **Multi-Threaded Concurrency (10 threads):** 94.8 spm. Scaling was sub-linear, as expected. The primary constraint shifted from client-side network latency to server-side resource allocation (likely script engine execution pools). Error rates (HTTP 429, 502) increased to approximately 2.1% at this level.
*   **Optimal Batch Size for Queue-Based Processing:** For our architecture, we found that queuing batches of 50 secrets, processed by 5 worker threads, yielded a reliable 48-52 spm with zero errors. This became our operational baseline.

Key technical observations for anyone planning similar workloads:
1.  The API response time is dominated by the rotation script runtime. A 30-second script creates a 30-second API call. Benchmark your own scripts independently.
2.  The `X-RateLimit-Remaining` header is present but unreliable under high concurrency; implement exponential backoff on HTTP 429.
3.  For true bulk operations, the `POST /api/v1/secrets/change-password` endpoint (which updates the secret's password without executing the full rotation logic) is an order of magnitude faster but bypasses audit trails and workflow hooks—a critical trade-off.

These numbers have directly informed our cost model. At ~50 spm, rotating a portfolio of 10,000 secrets requires just over 3 hours of dedicated processing time, which impacts scheduling and compute resource reservation for our orchestration layer. I am keen to hear if others have conducted similar benchmarks, particularly with different secret types (e.g., SSH keys, AWS IAM) or in different hosting models (on-prem vs. cloud). Discrepancies in throughput can significantly alter TCO calculations for large-scale automation initiatives.

— Data-driven decisions.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-delinea/">Delinea Reviews</category>                        <dc:creator>Catherine Liu</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-delinea/delinea-api-real-throughput-numbers-for-secret-rotation/</guid>
                    </item>
				                    <item>
                        <title>Showcase: How we do quarterly access reviews now</title>
                        <link>https://communities.stackinsight.net/community/cyber-delinea/showcase-how-we-do-quarterly-access-reviews-now/</link>
                        <pubDate>Tue, 21 Jul 2026 02:03:31 +0000</pubDate>
                        <description><![CDATA[Our quarterly access review process used to be a three-week odyssey of spreadsheets, manual verification, and stakeholder nagging. It was a classic case of a necessary control being so burde...]]></description>
                        <content:encoded><![CDATA[Our quarterly access review process used to be a three-week odyssey of spreadsheets, manual verification, and stakeholder nagging. It was a classic case of a necessary control being so burdensome that it encouraged shortcuts. Since integrating Delinea's Secret Server and its PAM Command API into our CI/CD pipeline, we've transformed it into a largely automated, evidence-based workflow that completes in under 48 hours. The key shift was moving from asking "Who has access?" to continuously validating "Who *needs* this access, and can prove it?"

We built a system that treats access as ephemeral, requiring justification. The core of the automation is a Python service that, triggered by our scheduler, executes the following steps:

1.  **Inventory &amp; Correlation:** It pulls a current list of all non-personal secrets from Delinea's API, then correlates them with our CMDB and IAM systems to generate a matrix of `(secret, user/role, business_context)`.
2.  **Ticket Generation:** For each unique `(user, business_context)` combination, it creates a ticket in Jira Service Management, assigned to the relevant application or team owner. The ticket contains specific secret names and a link to the automated justification portal.
3.  **Justification Workflow:** The team owner accesses a simple internal portal. They must either:
    *   **Attest:** Select a pre-approved justification (e.g., "Production deployment service account," "Quarterly financial reconciliation") and specify a renewal period (1-4 quarters).
    *   **Revoke:** Initiate an immediate revocation, which triggers an automated API call to Delinea to remove the user/group from the secret's permissions.
4.  **Evidence Capture &amp; Enforcement:** All attestations are logged with timestamp, user, and selected justification in a read-only audit database. If a ticket lapses past the deadline with no action, the system escalates it and, if still unresolved, initiates a revocation workflow as a safety measure.

The critical technical component is Delinea's REST API, which allows us to manage permissions programmatically. A simplified version of our revocation script is below:

```python
import requests
from delinea_api import SecretServer  # Internal wrapper class

def revoke_access(secret_id, user_principal):
    ss = SecretServer()
    # Fetch current secret permissions
    secret = ss.get_secret(secret_id)
    permissions = secret

    # Find and remove the specific user's permission entry
    new_permissions = [
        p for p in permissions
        if not (p == user_principal or p == user_principal)
    ]

    # Update secret with revised permissions
    if len(new_permissions) != len(permissions):
        update_payload = {'permissions': new_permissions}
        ss.update_secret(secret_id, update_payload)
        log_audit_event(secret_id, "REVOKED", user_principal)
        return True
    return False
```

**Results &amp; Pitfalls:**

*   **Reduced Scope:** Over four quarters, we've reduced standing privileged access by approximately 65% by forcing the "why" conversation.
*   **Audit Ready:** We now have a immutable audit trail linking every secret access to a business justification, not just an owner's signature on a spreadsheet.
*   **Key Pitfall:** The initial mapping of secrets to business owners was a significant, manual effort. We underestimated the data hygiene required in our CMDB. Garbage in, garbage out.
*   **Necessary Complement:** This works because Delinea is our system of record for *privileged* credentials. It does not replace our broader IGA tool for standard user account reviews. They are complementary processes.

This approach has shifted the cultural mindset. Access is now viewed as a temporary grant requiring periodic re-validation, not a permanent entitlement. The automation removes the toil, allowing our security team to focus on investigating anomalies rather than chasing down managers for signatures.

-- alex]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-delinea/">Delinea Reviews</category>                        <dc:creator>Alex Gray</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-delinea/showcase-how-we-do-quarterly-access-reviews-now/</guid>
                    </item>
				                    <item>
                        <title>Real experience with Delinea support and implementation</title>
                        <link>https://communities.stackinsight.net/community/cyber-delinea/real-experience-with-delinea-support-and-implementation/</link>
                        <pubDate>Mon, 20 Jul 2026 19:56:45 +0000</pubDate>
                        <description><![CDATA[Considering them for PAM? Their sales pitch is smooth. The reality, less so.

Implementation was... optimistic. Their timeline assumed we had no other projects. The actual deployment took tw...]]></description>
                        <content:encoded><![CDATA[Considering them for PAM? Their sales pitch is smooth. The reality, less so.

Implementation was... optimistic. Their timeline assumed we had no other projects. The actual deployment took twice as long, and that's with our team doing heavy lifting. Surprise costs appeared:
* Professional services for "environment validation" (their pre-sales assessment missed our AD structure)
* Additional connector fees for cloud targets not on the standard list
* The training included was uselessly generic. Real admin training was an extra SKU.

Support is a mixed bag. For critical "break-glass" issues, they're okay. For anything else—configuration, best practices—you're on your own forums. The response is often "that's a consulting engagement."

Biggest pitfall? The data migration from our old tool. Their provided scripts failed silently. We lost a week reconciling privilege assignments.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-delinea/">Delinea Reviews</category>                        <dc:creator>craigs</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-delinea/real-experience-with-delinea-support-and-implementation/</guid>
                    </item>
							        </channel>
        </rss>
		