Join our Newsletter — 33% off our NHI Course

Notifications
Clear all

Continuous testing and passwordless auth: what teams need to weigh


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 18936
Topic starter  

TL;DR: Resilient security programs depend on continuous testing, intentional vendor evaluation, and governance that lets teams adopt passwordless authentication and AI safely without sacrificing culture or operational focus, according to Sprocket Security’s interview with MacArthur Foundation engineer Seth Arnoff. The practical lesson is that measurable risk reduction matters more than one-off reports or fear-based leadership messaging.

NHIMG editorial — based on content published by Sprocket Security: an interview with Seth Arnoff on resilient security programs, passwordless authentication, AI guardrails, and continuous testing

By the numbers:

Questions worth separating out

Q: How should security teams use continuous penetration testing alongside vulnerability scanning?

A: Use vulnerability scanning to maintain breadth and coverage, then use continuous penetration testing to validate which findings are actually exploitable.

Q: When does passwordless authentication create more risk than it reduces?

A: It creates more risk when organisations adopt it without strong device governance, fallback controls, or recovery rules.

Q: What do security teams get wrong about AI access risk?

A: Many teams focus on the model while ignoring the identity path that reaches it.

Practitioner guidance

  • Turn penetration testing into a recurring remediation loop Define a continuous testing cadence, assign every finding to an owner, and require revalidation after remediation so the test programme proves control improvement rather than generating static reports.
  • Document passwordless recovery and exception paths early Map enrollment, device trust, fallback authentication, and account recovery before broad rollout so passwordless authentication does not create unmanaged identity exceptions.
  • Set AI usage rules around data, not slogans Create explicit policies for what data may be sent to AI tools, involve legal in the review process, and use usage trends to target training without over-collecting employee activity data.

What's in the full article

Sprocket Security's full interview covers the operational detail this post intentionally leaves for the source:

  • How MacArthur Foundation approaches continuous penetration testing as a living assurance process rather than a yearly exercise
  • The practical communication and trust patterns behind the move to Windows Hello passwordless authentication
  • How the team frames AI usage rules, legal review, and vendor assessment without relying on blanket prohibition
  • What security leaders should report to executives when they want measurable risk reduction instead of attention-grabbing metrics

👉 Read Sprocket Security's interview on continuous testing, passwordless auth, and AI guardrails →

Continuous testing and passwordless auth: what teams need to weigh?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 18527
 

Continuous validation is becoming a governance requirement, not a maturity luxury. Annual testing and static assurance artefacts cannot keep pace with modern exposure, especially where access paths, credentials, and external dependencies change constantly. Continuous penetration testing only has value when it is tied to remediation proof, not just discovery volume. Practitioners should treat validation cadence as part of control design, not a separate assurance exercise.

A question worth separating out:

Q: How should organisations assess third-party risk when vendors touch sensitive workflows?

A: Use repeatable criteria for every vendor, especially around access scope, data handling, evidence quality, and offboarding. The point is not to create a larger questionnaire, but to make decisions consistent enough to audit and defend. For sensitive workflows, vendor access should be time-bound, reviewed, and removed as part of the same process.

👉 Read our full editorial: Continuous testing and passwordless auth without burning out security teams



   
ReplyQuote
Share: