Hi everyone. I’m fairly new to Absolute Secure Access and have been tasked with defining and implementing some custom security policies for our team’s setup. We’re a mid-sized product team using a mix of Jira and Linear, and our main goal is to ensure secure access to internal tools based on role, location, and device posture.
I’ve reviewed the default policies, but they don’t quite match our specific needs. For instance, we need to differentiate access rules for contractors (who only use certain web apps) versus full-time developers (who need SSH and database access), and also factor in whether the device is company-managed.
Could someone clarify the recommended starting point? I’m particularly interested in understanding the practical differences between building policies from scratch versus duplicating and modifying the existing templates. What are the common pitfalls in structuring the rule order for these more granular use cases?
Thanks!
You're on the right track with the contractor vs FTE split. That's a classic starting point. Duplicate the closest default template, don't start from a blank slate - you'll miss baseline conditions.
The rule order pitfall you mentioned is where people get burned. Your most specific rules (like "contractors from region X accessing app Y") need to be at the TOP. The broader, catch-all "deny" goes at the bottom. I've seen teams accidentally put a broad "allow developers" rule first, which then lets contractors through because the system stops evaluating after the first match.
Have you quantified how many contractor logins you actually get per month? If it's under 50, the complexity of a super-granular policy might not be worth the management overhead versus just giving them a locked-down VDI session.
Show me the bill
I strongly agree with starting from a duplicated template, but I'd add a step: create a simple spreadsheet matrix of your user groups, resources, and required access levels before you even touch the policy console. This forces you to define the logic cleanly and makes the rule order pitfall user149 mentioned much easier to spot.
His point about quantifying logins is critical for prioritizing complexity. I'd extend that to also quantify the risk exposure. A policy for 5 logins a month might still be justified if those contractors are accessing a high-value financial system, not just a web app.
One caveat on the rule order advice: while "most specific at the top" is the golden rule, remember that "specific" can refer to a combination of conditions, not just one. A rule for "FTE, company-managed device, from office IP" should be above "FTE, any device," even though both are about FTEs.
Method over hype
Totally agree on duplicating a template, that saved me weeks when I set up our first ones. Your point about the broad "allow developers" rule is spot on - I made that exact mistake early on and it took a debugging session to figure out why test contractor accounts were getting permissions they shouldn't.
That VDI suggestion for low-volume logins is a great pragmatic alternative. Sometimes we over-engineer the policy engine when a simpler access method exists. Have you found any quirks with how the system evaluates "company-managed device" posture? I've seen some inconsistency there depending on the endpoint agent version.
Yeah, that rule order mistake seems to be a common rite of passage.
On the VDI versus granular policies point, is the cost of a VDI seat for low-volume contractors ever a deciding factor compared to the engineering time spent on policies? I'm always weighing that.
> Have you found any quirks with how the system evaluates "company-managed device" posture?
I've heard this too, but haven't deployed it at scale yet. What kind of inconsistencies did you see? Was it OS-specific or purely agent version?