Skip to main content

⚙️🪟💻🔓CP - Security - Screen Lock Timer - Disable

What this policy is for 🔓​

This is the counter-policy to ⚙️🪟💻CP - Security - Screen Lock Timer.

While that one automatically locks screens after inactivity (because, you know, security), this one says:

"Okay, fine. But only for specific users who have a really good reason."

Why? Because in real-world scenarios, sometimes you need exceptions:

  • Presentation devices — Screens that display dashboards, metrics, or live data 24/7
  • Demo accounts — Sales or training accounts where auto-lock would interrupt workflows
  • Specific use cases — Where the user environment is already physically secured (e.g., locked server rooms, controlled access areas)

This policy disables the auto-lock timer — but only for those assigned to the 🛡️🪟💻👈🔓Group - Screen Lock Timer Disabled

🛠️ Configuration Settings​

SettingValueWhy
Device Password EnabledEnabledStill requires a password when manually locked or on startup
Max Inactivity Time Device Lock0Disables automatic screen lock (0 = never auto-lock)

Yes, we're setting it to 0. Yes, that's the thing we warned against in the main policy.

But here's the difference: This is intentional, documented, and assigned to a specific group with a clear business justification.

Not chaos. Controlled exceptions.

💡 SuperVision Tips​

🎯 Use the Same Dynamic Tag System​

Just like the main policy, you can use SuperVision's Golden Master to make this dynamic:

  1. Click the tag button next to the lock timer field in SuperVision
  2. Set the default value to 0 (disabled)
  3. If a customer wants a different "no auto-lock" behavior, you can override it

Though let's be honest: if you're disabling auto-lock, you're probably setting it to 0. But flexibility is still nice.

⚠️ This is an Exception, Not the Rule​

This policy should be used sparingly.

It's for:

  • Dashboard displays in secure areas
  • Demo or training devices with no sensitive data
  • Presentation systems where auto-lock would disrupt operations

It's not for:

  • "Bob doesn't like locking his screen"
  • "The CEO said it's annoying"
  • "Can we just turn it off for everyone?"

If someone asks for this without a solid justification, the answer is: No.

And then you point them to the main policy and walk away like Tony Stark after dropping a one-liner.

👥 Group Assignments​

✅ Included groups:​

❌ Excluded groups:​

📝 Governance Check​

If you enable this policy without understanding why a device needs it, you're basically handing Loki the Tesseract and hoping for the best.

Always combine this with:

  • A written justification from the customer (email, ticket, carrier pigeon — we don't care, just document it)
  • Internal documentation of why this exception exists
  • Regular review of who's in the group (because "temporary" exceptions have a habit of becoming permanent)

🦸‍♂️ The "With Great Power" Reminder​

Remember what Uncle Ben said? "With great power comes great responsibility."

This policy gives you the power to disable a core security control.

Use it wisely. Use it rarely. And always — always — with justification.

Because the moment you start handing out exceptions like candy, you're no longer managing security. You're managing chaos.

And chaos is Loki's job. Not yours.

Final Thoughts 🧘​

Exception policies exist for a reason: real-world flexibility.

Not every device fits the same mold. Not every use case is standard.

But exceptions should be:

  • Documented ✅
  • Justified ✅
  • Reviewed regularly ✅
  • Assigned to a specific group ✅

Do this right, and you're a security hero. Do this wrong, and you're the reason the next audit fails.

Standardize like a pro. Configure with intent. And remember: exceptions are fine — as long as you can explain them to an auditor.