How SN does its credentials storage for discovery
The bottom line is that the credentials are escrowed in the instance. [1] Though they are stored on disk as 3DES ciphertext, SN holds the key. To make matters worse, this key is hard-coded, and it's the same across all SN customers. So basically we'd be trusting SN with semi-priveleged/privileged access credentials for a rather large number of Yale systems.
They've had 2 other customers work with them to provide an better way of doing this (using a customer-managed PIM solution) only to have the customers pull out mid-way due to cost/time constraints. Since we've signed the SOW, this work would presumably incur additional cost. So the question remains whether ISO will sign off on this or compel us to fix it, and whether the sponsor can/will pay for that.
Wearing my sysadmin hat: if this persists as a condition of use, I would be very much against permitting discovery of the boxes for which I'm responsible. If the other groups have any sense (and I'm sure they do), they'll feel the same way.
[1] - http://wiki.service-now.com/index.php?title=Discovery_FAQ